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

Я створив програму, спробував розмістити рядок на сайті, і я отримав цю помилку:

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

після цього рядка коду:

gResponse = (HttpWebResponse)gRequest.GetResponse(); 

Як я можу виправити цей виняток?

Спробуйте помістити це у свою програму / web.config:

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

Якщо це не працює, ви також можете спробувати встановити KeepAliveвластивість на значення false.

Іноді ця помилка виникає, коли UserAgentпараметр запиту порожній (у моєму випадку apith github.com).

Встановлення цього параметра у власному не порожньому рядку вирішило мою проблему.

Винувателем у моєму випадку було повернення 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виводить BOM, і це легко забути. Веб-сторінки будуть працювати належним чином у Firefox та Chrome, але HttpWebRequestбудуть бомби :). Швидке виправлення полягає в тому, щоб змінити веб-сервер на використання кодування UTF-8, яке не виводить BOM, наприклад new UTF8Encoding(false)(це нормально, поки Response-Phraseєдиний містить символи ASCII, але насправді він повинен використовуватись ASCIIабо ISO-8859-1для заголовків, а потім UTF-8або якесь інше кодування для відповіді).

Установка очікує, що 100 продовжить помилково, а скорочення часу роботи в режимі простою до двох секунд вирішило проблему для мене

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

Скайп був основною причиною моєї проблеми:

Ця помилка зазвичай виникає, коли ви налаштували Visual Studio для налагодження існуючої веб-програми, що працює в IIS, а не вбудованого веб-сервера налагодження ASP.NET . IIS за замовчуванням прослуховує веб-запити на порт 80. У цьому випадку інша програма вже прослуховує запити на порт 80. Зазвичай програмою, яка порушує правила, є Skype, який за замовчуванням приймає прослуховування на портах 80 і 443 при встановленні. Skype вже займає порт 80. Отже, IIS не може запуститися.

Щоб вирішити проблему, виконайте наступні дії:

Skype -> Інструменти -> Опції -> Додатково -> Підключення:

Зніміть прапорець "Використовувати порти 80 та 443 як альтернативи вхідним з'єднанням".

І як зазначено нижче, виконайте скидання IIS після завершення.

Я спробував отримати доступ до 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, тому я використав рішення, розміщене Павлом Саварою у цій темі - Використання CookieContainer з класом WebClient

просто видаліть "захищений" з цього рядка:

приватний контейнер CookieContainer для читання лише новий CookieContainer ();

Ймовірна причина цієї проблеми - конфігурація протоколу автоматичного виявлення веб-проксі (WPAD) у мережі. Запит HTTP буде прозоро відправлений до проксі, який може надіслати відповідь, яку клієнт не прийме або не налаштований прийняти. Перш ніж зламати код на біти, переконайтеся, що WPAD не відтворюється, особливо, якщо це просто "почалося" невдало.

Моєю проблемою було те, що я подзвонив у httpsкінцеву точку http.

Перше, що ми намагалися - це відключити динамічне стиснення вмісту для IIS, що вирішило помилки, але помилка не була викликана стороною сервера, і це вплинуло лише на одного клієнта.

На стороні клієнта ми видалили VPN-клієнтів, скинули налаштування Інтернету та знову встановили VPN-клієнти. Помилка також може бути викликана попереднім антивірусом, який мав брандмауер. Тоді ми ввімкнули динамічне стиснення вмісту, і тепер він працює чудово, як і раніше.

Помилка з’явилася у користувацькому додатку, який підключається до веб-служби, а також у TFS.

У моєму випадку IIS не мав необхідних дозволів для доступу до відповідного шляху ASPX.

Я дав дозволи користувача IIS у відповідний каталог і все було добре.

Перегляньте свій код і знайдіть, чи встановлюєте ви якийсь заголовок з NULL або порожнім значенням.

Я почав отримувати цю помилку з моїх служб php JSON / REST

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

Я вмію користуватися просто ob_start(), і все добре.