Sunucu bir protokol ihlali yaptı. Bölüm = ResponseStatusLine ERROR

Bir program oluşturdum, bir siteye bir dize göndermeyi denedim ve şu hatayı alıyorum:

"Sunucu bir protokol ihlali yaptı. Bölüm = ResponseStatusLine"

bu kod satırından sonra:

gResponse = (HttpWebResponse)gRequest.GetResponse(); 

Bu istisnayı nasıl düzeltebilirim?

Bunu app / web.config dosyanıza eklemeyi deneyin:

<system.net>
    <settings>
        <httpWebRequest useUnsafeHeaderParsing="true" />
    </settings>
</system.net>

Bu işe yaramazsa, KeepAliveözelliği false olarak ayarlamayı da deneyebilirsiniz .

Bazen bu hata UserAgentistek parametresi boş olduğunda meydana gelir (benim durumumda github.com api'de).

Bu parametreyi özel olarak boş değil dizge olarak ayarlamak sorunumu çözdü.

Benim durumumdaki suçlu bir No Contentyanıt veriyordu ama aynı zamanda bir yanıt gövdesini tanımlıyordu. Bu cevap bana ve belki başkalarına bir daha bedenle cevap vermemeleriniNoContent hatırlatsın .

Bu davranış ile tutarlıdır 10.2.5 204 Hiçbir İçerik ait HTTP şartname diyor ki:

204 yanıtı bir mesaj gövdesi İÇERMEMELİDİR ve bu nedenle her zaman başlık alanlarından sonraki ilk boş satırla sonlandırılır.

Başka bir olasılık: POST yaparken, sunucu yanlış bir şekilde 100 devam ile yanıt verir.

Bu benim için sorunu çözdü:

request.ServicePoint.Expect100Continue = false;

Bu, yerel makinemde Skype çalışırken benim için oluyordu. Kapatır kapatmaz istisna ortadan kalktı.

Bu sayfanın izniyle fikir

Bunda hata ayıklamanın bir yolu (ve soruna neden olanın protokol ihlali olduğundan emin olmanın), Fiddler'ı (Http Web Proxy) kullanmak ve aynı hatanın oluşup oluşmadığını görmektir. Aksi takdirde (yani Fiddler sorunu sizin için halletmişse), UseUnsafeHeaderParsing bayrağını kullanarak düzeltebilmelisiniz.

Bu değeri programatik olarak ayarlamanın bir yolunu arıyorsanız buradaki örneklere bakın: http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline /

Çoğu çözüm, bir geçici çözümden bahseder, ancak hatanın gerçek nedeni hakkında değildir.

Webserver dışında bir kodlama kullanırsa, bu hatanın olası bir nedeni olan ASCIIve ISO-8859-1başlık tepki bölümü çıkış. Kullanmanın nedeni ISO-8859-1,Response-Phrase , genişletilmiş Latin karakterleri içeriyorsa .

Bu hatanın başka bir olası nedeni, bir web sunucusunun UTF-8bayt sırası işaretini (BOM) çıkaran kullanmasıdır . Örneğin, varsayılan sabit Encoding.UTF8, ürün reçetesinin çıktısını alır ve bunu unutmak kolaydır. Web sayfaları, Firefox ve Chrome'da düzgün çalışacak, ancakHttpWebRequest bombalayacak :). Hızlı bir düzeltme çıkış BOM, mesela değil UTF-8 kodlaması kullanmak için web sunucusu değiştirmektir new UTF8Encoding(false)sürece kadar sorun yok ( Response-Phraseyalnızca ASCII karakterleri içerir, ancak gerçekten kullanmalıdır ASCIIveya ISO-8859-1başlıklarının için, sonra UTF-8ya yanıt için başka bir kodlama).

100 beklentisi ayarı yanlış olmaya devam ediyor ve soket boşta kalma süresini iki saniyeye düşürmek benim için sorunu çözdü

ServicePointManager.Expect100Continue = false; 
ServicePointManager. MaxServicePointIdleTime = 2000; 

Skype, sorunumun ana nedeniydi:

Bu hata genellikle, Visual Studio'yu yerleşik ASP.NET yerine IIS'de çalışan mevcut bir web uygulamasında hata ayıklamak için ayarladığınızda oluşur hata ayıklama web sunucusu . IIS varsayılan olarak 80 numaralı bağlantı noktasındaki web isteklerini dinler. Bu durumda başka bir uygulama 80 numaralı bağlantı noktasındaki istekleri zaten dinlemektedir. Tipik olarak sorun teşkil eden uygulama, kurulduğunda varsayılan olarak 80 ve 443 numaralı bağlantı noktalarında dinlemeyi devralan Skype'tır. Skype zaten 80 numaralı bağlantı noktasını işgal ediyor. Bu nedenle IIS başlatılamıyor.

Sorunu çözmek için aşağıdaki adımları izleyin:

Skype -> Araçlar -> Seçenekler -> Gelişmiş -> Bağlantı:

"Gelen bağlantılar için alternatif olarak bağlantı noktası 80 ve 443'ü kullan" seçeneğinin işaretini kaldırın.

Ve aşağıda belirtildiği gibi , tamamlandığında bir IIS sıfırlaması gerçekleştirin.

Last.fm Rest API'ye bir proxy arkasından erişmeye çalıştım ve bu ünlü hatayı aldım.

Sunucu bir protokol ihlali yaptı. Bölüm = ResponseStatusLine

Bazı geçici çözümleri denedikten sonra, sadece bu ikisi benim için çalıştı

HttpWebRequest HttpRequestObj = WebRequest.Create(BaseUrl) as HttpWebRequest;
HttpRequestObj.ProtocolVersion = HttpVersion.Version10;

ve

HttpWebRequest HttpRequestObj = WebRequest.Create(BaseUrl) as HttpWebRequest;
HttpRequestObj.ServicePoint.Expect100Continue = false;

Çözümlerden hiçbiri benim için işe yaramadı, bu yüzden bir HttpWebRequest yerine bir WebClient kullanmak zorunda kaldım ve sorun artık yoktu.

Bir CookieContainer kullanmam gerekti, bu yüzden Pavel Savara tarafından bu ileti dizisinde yayınlanan çözümü kullandım - CookieContainer'ı WebClient sınıfıyla kullanma

sadece bu satırdan "korumalı" ifadesini kaldırın:

özel salt okunur CookieContainer container = new CookieContainer ();

Bu sorunun olası bir nedeni, ağdaki Web Proxy Otomatik Bulma Protokolü (WPAD) yapılandırmasıdır. HTTP isteği, istemcinin kabul etmeyeceği veya kabul edecek şekilde yapılandırılmamış bir yanıtı geri gönderebilen bir proxy'ye şeffaf bir şekilde gönderilir. Kodunuzu parçalara ayırmadan önce, WPAD'in oyunda olmadığını, özellikle de birdenbire "olmaya başladıysa" kontrol edin.

Benim sorunum, httpsuç noktayı aramamdı http.

Denediğimiz ilk şey, IIS için dinamik içerik sıkıştırmayı devre dışı bırakmaktı, bu hataları çözdü, ancak hata sunucu tarafında neden olmadı ve bundan yalnızca bir istemci etkilendi.

İstemci tarafında VPN istemcilerini kaldırdık, internet ayarlarını sıfırladık ve ardından VPN istemcilerini yeniden yükledik. Hata, güvenlik duvarı olan önceki antivirüslerden de kaynaklanıyor olabilir. Sonra dinamik içerik sıkıştırmasını geri etkinleştirdik ve şimdi eskisi gibi iyi çalışıyor.

Bir web hizmetine bağlanan özel uygulamada ve ayrıca TFS'de hata oluştu.

Benim durumumda IIS, ilgili ASPX yoluna erişmek için gerekli izinlere sahip değildi.

IIS kullanıcı izinlerini ilgili dizine verdim ve her şey yolundaydı.

Kodunuza bakın ve NULL veya boş değer içeren bir başlık ayarlayıp ayarlamadığınızı bulun.

Bu hatayı php JSON / REST servislerimden almaya başladım

ob_start("ob_gzhandler")En sık erişilen GET php betiğine ekledikten sonra relativley nadir POST yüklemelerinden hata almaya başladım

Sadece kullanabiliyorum ob_start()ve her şey yolunda.