Я создал программу, попытался опубликовать строку на сайте, и я получаю эту ошибку:
"Сервер совершил нарушение протокола. Раздел = ResponseStatusLine"
после этой строки кода:
gResponse = (HttpWebResponse)gRequest.GetResponse();
Как я могу исправить это исключение?
Попробуйте поместить это в ваше приложение /web.config:
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true" />
</settings>
</system.net>
Если это не сработает, вы также можете попробовать установить для свойства KeepAlive значение false.
Иногда эта ошибка возникает, когда параметр запроса UserAgent пуст (в github.com api в моем случае).
Установка этого параметра в пользовательскую непустую строку решает мою проблему.
Преступник в моем случае возвращал ответ No Content, но одновременно определял тело ответа. Пусть этот ответ напомнит мне и, возможно, другим не возвращать ответ NoContent с телом снова.
Это поведение согласуется с 10.2.5 204 Нет содержимого HTTP-спецификации, в котором говорится:
Ответ 204 НЕ ДОЛЖЕН включать тело сообщения и, следовательно, всегда завершается первой пустой строкой после полей заголовка.
Другая возможность: при выполнении POST сервер реагирует на 100 продолжить неправильным образом.
Это решило проблему для меня:
request.ServicePoint.Expect100Continue = false;
Это происходило для меня, когда у меня был Skype, работающий на моей локальной машине. Как только я закрыл, исключение ушло.
Один из способов отладить это (и убедиться, что это нарушение протокола, вызывающего проблему), - использовать Fiddler (Http Web Proxy) и посмотреть, происходит ли такая же ошибка. Если это не так (то есть Fiddler обработал проблему для вас), вы должны исправить ее с помощью флажка UseUnsafeHeaderParsing.
Если вы ищете способ установить это значение, программно см. примеры здесь: http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline/
Многие решения говорят об обходном пути, но не о фактической причине ошибки.
Одна из возможных причин этой ошибки заключается в том, что веб-сервер использует кодировку, отличную от 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 или другую кодировку для ответа).
Ожидание установки 100 продолжит ложь и уменьшит время простоя сокета до двух секунд, разрешив проблему для меня
ServicePointManager.Expect100Continue = false;
ServicePointManager. MaxServicePointIdleTime = 2000;
Skype был основной причиной моей проблемы:
Эта ошибка обычно возникает, если вы настроили Visual Studio на отладку существующего веб-приложения , работающего в IIS, а не на встроенном веб-сервере ASP.NET. IIS по умолчанию прослушивает веб-запросы на порт 80. В этом случае другое приложение уже прослушивает запросы на порт 80. Как правило, нарушающим приложением является Skype, который по умолчанию берет на себя прослушивание портов 80 и 443 при установке. Skype уже занимает порт 80. Поэтому IIS не может запускаться.
Чтобы устранить проблему, выполните следующие действия:
Skype → Инструменты → Параметры → Дополнительно → Соединение:
Снимите флажок "Использовать порт 80 и 443 в качестве альтернативы входящим соединениям".
И как указано ниже выполнить IIS reset после выполнения.
Я попытался получить доступ к API Last.fm Rest из-за прокси-сервера и получил эту известную ошибку.
Сервер совершил нарушение протокола. Раздел = ResponseStatusLine
Попробовав некоторые обходные пути, только эти двое работали для меня
HttpWebRequest HttpRequestObj = WebRequest.Create(BaseUrl) as HttpWebRequest;
HttpRequestObj.ProtocolVersion = HttpVersion.Version10;
и
HttpWebRequest HttpRequestObj = WebRequest.Create(BaseUrl) as HttpWebRequest;
HttpRequestObj.ServicePoint.Expect100Continue = false;
Ни один из решений не работал у меня, поэтому мне пришлось использовать WebClient вместо HttpWebRequest, и проблема была не более.
Мне нужно было использовать CookieContainer, поэтому я использовал решение, опубликованное Pavel Savara в этой теме - Использование CookieContainer с классом WebClient
просто удалите "защищенный" из этой строки:
private readonly CookieContainer container = new CookieContainer();
Моя проблема заключалась в том, что я позвонил в конечную точку https с http.
Вероятной причиной этой проблемы является конфигурация протокола автоматического обнаружения веб-прокси (WPAD) в сети. HTTP-запрос будет прозрачно отправлен на прокси-сервер, который может отправить ответ, который клиент не примет или не настроен на прием. Прежде чем взломать ваш код на кусочки, убедитесь, что WPAD не работает, особенно если это просто "начало происходить" на ровном месте.
В первую очередь мы пытались отключить динамическое сжатие содержимого для IIS, которое решило ошибки, но ошибка не была вызвана сервером, и на него повлиял только один клиент.
На стороне клиента мы удалили VPN-клиенты, reset параметры Интернета, а затем повторно установили VPN-клиенты. Ошибка также может быть вызвана предыдущим антивирусом с брандмауэром. Затем мы включили обратно динамическое сжатие содержимого, и теперь оно отлично работает как раньше.
Ошибка в пользовательском приложении, которое подключается к веб-службе, а также к TFS.
В моем случае у IIS не было необходимых разрешений для доступа к соответствующему пути ASPX.
Я предоставил разрешения пользователей IIS в соответствующий каталог, и все было хорошо.
Посмотрите на свой код и найдите, если вы устанавливаете некоторый заголовок с NULL или пустым значением.
Я начал получать эту ошибку из моих служб php JSON/REST
Я начал получать ошибку из релятививных редких POST-загрузок после добавления ob_start("ob_gzhandler") к наиболее часто используемому GET PHP скрипт
Я могу использовать только ob_start(), и все в порядке.