Сервер совершил нарушение протокола. Раздел = ResponseStatusLine ERROR

115

Я создал программу, попытался разместить строку на сайте и получил такую ошибку:

«Сервер совершил нарушение протокола. Раздел = ResponseStatusLine»

после этой строки кода:

gResponse = (HttpWebResponse)gRequest.GetResponse();

Как я могу исправить это исключение?

c# httpwebrequest

— Manish Patel
источник

71

Попробуйте поместить это в свой app / web.config:

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

Если это не сработает, вы также можете попробовать установить для KeepAliveсвойства значение false.

— Дарин Димитров
источник

3

У меня было 6 URL-адресов с этой ошибкой. Установка useUnsafeHeaderParsing исправила это для одной ссылки, но установка KeepAlive = false исправила это для всех 6.

— Дэвид Хаммонд

3

То же самое можно поместить в корневой тег <configuration> в App.copnfig для не веб-приложений (например, я исправил приложение WPF таким образом - спасибо!).

— Юрий Щкатула

кто-нибудь знает, почему эта мера безопасности вводится IIS? Это сработало, но я не понимаю причину ограничения значений заголовков (в моем случае их устанавливаю вручную).

— emran

26

Это просто позволяет избежать проблемы, а не исправить ее. Я думаю, это не должно быть решением по умолчанию.

— Тобиас

4

Согласитесь с Тобиасом - вы избегаете проблемы. Теперь может быть, что проблема в сервере, который вы не можете исправить, и поэтому избегание может быть вашим единственным вариантом ... но все же давайте проясним разницу между избежанием ошибки протокола и фактическим ее исправлением.

— metaforge

58

Иногда эта ошибка возникает, когда UserAgentпараметр запроса пуст (в моем случае в github.com api).

Установка этого параметра в пользовательскую непустую строку решила мою проблему.

— Иван Кочуркин
источник

5

А это то, что мне нужно. Спасибо. Вот пример пользовательского агента: stackoverflow.com/a/15144495/891976

— Дэвид Руманн

Быстрая строка для использования WebClientздесь stackoverflow.com/a/11841680/4795214

5

Спасибо. Если вы хотите запросить GitHub через строку HttpClient add: client.DefaultRequestHeaders.Add("User-Agent", "Anything");для исправления.

— Cihan Yakar

32

В моем случае виновник возвращал No Contentответ, но в то же время определял тело ответа. Пусть этот ответ напомнит мне и, возможно, другим никогда больше не возвращать NoContentответ с телом .

Такое поведение согласуется с 10.2.5 204 Нет содержания в спецификации HTTP , который говорит:

Ответ 204 НЕ ДОЛЖЕН включать тело сообщения и, таким образом, всегда заканчивается первой пустой строкой после полей заголовка.

— Тобиас
источник

Просто прочтите это после того, как я получил сообщение об The server committed a protocol violation. Section=ResponseStatusLine ошибке при использовании WebApi для возврата настраиваемого NoContent()ответа, который отправлялся No Contentв ответе по какой-то странной причине! Как только я вытащил это, проблема исчезла :)

— Intrepid

2

Это также было моей проблемой, хотя это было сложно, потому что это был вызов ПОСЛЕ ответа No Content, который не работал.

— mdickin 07

Исправлено удалением someContentиз return Request.CreateResponse(HttpStatusCode.NoContent, someContent); +1

— snippetkid

12

Другая возможность: при выполнении POST сервер неверно отвечает 100 продолжением.

Это решило проблему для меня:

request.ServicePoint.Expect100Continue = false;

— MARQ
источник

У меня это сработало при доступе к MediaFire API.

— AlexPi

3

Я знаю, что опаздываю, но что вы имеете в виду, говоря «неправильно»?

— kuskmen

1

Для всех, кто использует HttpClient , у меня сработало следующее:var http = new HttpClient(); http.DefaultRequestHeaders.ExpectContinue = false;

— user2444499

9

Это происходило со мной, когда на моем локальном компьютере был запущен Skype. Как только я закрыл это исключение, исчезло.

Идея любезно предоставлена этой страницей

— Люк
источник

Была такая же проблема. Оказался скайп. Это настолько прискорбно, что невозможно предоставить правильные сообщения.

— jordan koskei

на самом деле вам не нужно закрывать Skype, я добавил ответ ниже, чтобы показать, как решить эту проблему, не закрывая Skype.

— AltF4_ 02

8

Один из способов отладить это (и убедиться, что проблема связана с нарушением протокола) - использовать Fiddler (Http Web Proxy) и посмотреть, возникает ли та же ошибка. Если это не так (т.е. Fiddler обработал проблему за вас), вы сможете исправить ее с помощью флага UseUnsafeHeaderParsing.

Если вы ищете способ установить это значение программно, см. Примеры здесь: http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline /

— Динис Крус
источник

Fiddler действительно решает проблему с HTTP-запросом GET. Можем ли мы увидеть, что делает скрипач?

— Olivier MATROT

8

Во многих решениях говорится об обходном пути, но не о фактической причине ошибки.

Одна из возможных причин этой ошибки - использование веб-сервером кодировки, отличной от ASCIIили ISO-8859-1для вывода раздела ответа заголовка. Причина использования ISO-8859-1- если он Response-Phraseсодержит расширенные латинские символы.

Другая возможная причина этой ошибки - использование веб UTF-8-сервером маркера порядка байтов (BOM). Например, константа по умолчанию Encoding.UTF8выводит спецификацию, и об этом легко забыть. Веб-страницы будут корректно работать в Firefox и Chrome, но HttpWebRequestбудут бомбить :). Быстрое исправление - изменить веб-сервер для использования кодировки UTF-8, которая не выводит спецификацию, например new UTF8Encoding(false)(что нормально, если Response-Phraseтолько содержит символы ASCII, но на самом деле он должен использовать ASCIIили ISO-8859-1для заголовков, а затем UTF-8или какая-то другая кодировка ответа).

— Ненависть
источник

Это лучший ответ. Это объясняет, почему веб-сервер плохо себя ведет. Спасибо! (Мне нужно эмулировать веб-сервер с сокетами из-за проблем с развертыванием HttpListener.)

— Эндрю Рондо,

6

Настройка expect 100 continue на false и сокращение времени простоя сокета до двух секунд решило проблему для меня.

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

— Прашан Пратап
источник

6

Skype был основной причиной моей проблемы:

Эта ошибка обычно возникает, когда вы настроили Visual Studio для отладки существующего веб-приложения, работающего в IIS, а не на встроенном веб-сервере отладки ASP.NET . IIS по умолчанию прослушивает веб-запросы через порт 80. В этом случае другое приложение уже прослушивает запросы через порт 80. Как правило, приложение-нарушитель - Skype, который по умолчанию прослушивает порты 80 и 443 при установке. Skype уже занимает порт 80. Итак, IIS не запускается.

Чтобы решить проблему, выполните следующие действия:

Skype -> Инструменты -> Параметры -> Дополнительно -> Подключение:

Снимите флажок «Использовать порт 80 и 443 в качестве альтернативы для входящих подключений».

И, как указано ниже, выполните сброс IIS после завершения.

— AltF4_
источник

2

и не забудьте перезапустить IIS после этого

— Ахмед Галал,

3

Я попытался получить доступ к Last.fm Rest API из-за прокси-сервера и получил эту знаменитую ошибку.

Сервер совершил нарушение протокола. Раздел = ResponseStatusLine

Попробовав обходные пути, у меня сработали только эти двое.

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

и

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

— nixda
источник

2

Ни одно из решений у меня не сработало, поэтому мне пришлось использовать WebClient вместо HttpWebRequest, и проблемы больше не было.

Мне нужно было использовать CookieContainer, поэтому я использовал решение, опубликованное Павлом Саварой в этом потоке - Использование CookieContainer с классом WebClient

просто удалите "protected" из этой строки:

закрытый только для чтения CookieContainer container = new CookieContainer ();

— ТД Тодоров
источник

2

Вероятной причиной этой проблемы является конфигурация протокола автоматического обнаружения веб-прокси (WPAD) в сети. HTTP-запрос будет прозрачно отправлен на прокси-сервер, который может отправить ответ, который клиент не примет или не настроен для принятия. Прежде чем взламывать свой код на части, убедитесь, что WPAD не работает, особенно если это «начало происходить» неожиданно.

— Skrymsli
источник

2

Моя проблема заключалась в том, что я позвонил в httpsконечную точку с помощью http.

— gneric
источник

1

Первым делом мы попытались отключить сжатие динамического содержимого для IIS, что решило ошибки, но ошибка не была вызвана серверной частью, и это затронуло только одного клиента.

На стороне клиента мы удалили VPN-клиенты, сбросили настройки Интернета, а затем переустановили VPN-клиенты. Ошибка также могла быть вызвана предыдущим антивирусом, у которого был брандмауэр. Затем мы включили сжатие динамического контента, и теперь оно работает нормально, как и раньше.

Ошибка появилась в пользовательском приложении, которое подключается к веб-сервису, а также в TFS.

— HasanG
источник

0

В моем случае у IIS не было необходимых разрешений для доступа к соответствующему пути ASPX.

Я дал пользователю IIS права доступа к соответствующему каталогу, и все было хорошо.

— Vaiden
источник

0

Посмотрите свой код и выясните, устанавливаете ли вы какой-либо заголовок с NULL или пустым значением.

— Абдул Рауф
источник

0

Я начал получать эту ошибку из моих служб php JSON / REST

Я начал получать ошибку от релятивно редких загрузок POST после того, как добавил ob_start("ob_gzhandler")к наиболее часто используемому сценарию GET php

Умею пользоваться просто ob_start(), и все нормально.

— Патрик
источник