Почему “Довольная Длина: 0” в запросах POST?

Internet Explorer не отправляет поля формы, если они отправляются от аутентифицируемого сайта (NTLM) на неаутентифицируемый (анонимный) сайт.

Это - функция ситуаций challange-ответа (NTLM-или Kerberos - защищенные веб-сайты), где IE может ожидать, что первый запрос POST сразу приводит к аутентификация HTTP 401, Требуемая ответ (который включает проблему), и только второй запрос POST (который включает ответ на проблему), будет на самом деле принят. В этих ситуациях IE не загружает возможно большое тело запроса с первым запросом по причинам производительности. Благодаря EricLaw для регистрации того бита информации в комментариях.

Это поведение происходит каждый раз, когда POST HTTP сделан из аутентифицируемого NTLM (т.е. Интранет) страница к неаутентифицируемому (т.е. Интернет) страница, или если неаутентифицируемая страница является частью frameset, где frameset страница аутентифицируется.

обходное решение должно или использовать ПОЛУЧИТЬ запрос в качестве метода формы, или удостоверяться, что неаутентифицируемая страница открыта на новой вкладке/окне (фаворит/цель ссылки) без частично аутентифицируемого frameset. Как только модель аутентификации для целого окна последовательна, IE начнет отправлять содержание формы снова.

<час>

• Определенно связанный: http://www.websina.com/bugzero/kb/browser-ie.html
• Возможно связанный: KB923155
• Полное Объяснение : Блог IEInternals †“Аутентификация типа "запрос-ответ" и Сообщения Нулевой Длины

Присутствие и возможные значения заголовка ContentLength в HTTP описаны в HTTP (я принимаю 1/1), RFC:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13

В HTTP, это ДОЛЖНО быть отправлено каждый раз, когда длина сообщения может быть определена до того, чтобы быть переданным

, См. также:

, Если сообщение получено и с Кодированием полей заголовков передачи и с полем заголовка Довольной Длины, последний ДОЛЖЕН быть проигнорирован. http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4

, Возможно, Ваше сообщение несет Кодирующий Передачу заголовок?

Более позднее редактирование: также отметьте, "ДОЛЖЕН", как используется в RFC, очень важно и не эквивалентен, "ДОЛЖЕН":

3. ЕСЛИ Это слово или "РЕКОМЕНДУЕМОЕ" прилагательное, означает, что там может существовать допустимые причины в особенности обстоятельства для игнорирования конкретного объекта, но полные последствия должны быть поняты и тщательно взвешены прежде, чем выбрать различный курс. Касательно: http://www.ietf.org/rfc/rfc2119.txt

Google также показывает это IE (некоторые версии, так или иначе) ошибка после того, как подключение HTTPS поразит тайм-аут проверки активности и снова соединится с сервером. Решение, кажется, настраивает сервер для не использования проверки активности для IE под https.

Это - известная проблема для Internet explorer 6, но не для 7, что я знаю о. Можно установить эту фиксацию для IE6 KB831167, фиксируют.

Вы можете читать больше об этом здесь .

Некоторые вопросы для Вас:

• Вы знаете который тип прокси?
• Вы знаете, существует ли фактическое тело, отправленное в запросе?
• это последовательно происходит каждый раз? Или только иногда?
• там какие-либо двоичные данные, отправленные в запросе? Возможно, данные запускаются с \0, и прокси имеет ошибку с двоичными данными.

существует хороший шанс, которым проблема состоит в том что прокси-сервер промежуточный HTTP 1.0 реализаций.

В HTTP 1.0 необходимо использовать поле заголовка Довольной Длины: ( раздел See 10.4 здесь )

А допустимая Довольная Длина требуется по всем запросам POST HTTP/1.0. Сервер HTTP/1.0 должен ответить 400 (плохой запрос) сообщение, если это не может определить длину содержания сообщения запроса.

запрос, входящий в прокси, является HTTP 1.1 и поэтому не должен использовать поле заголовка Довольной Длины. Заголовок Довольной Длины обычно используется, но не всегда. См. следующую выборку от , Приложения RFC S. 14.13 .

HTTP 1.1 ДОЛЖНЫ использовать это поле для указания на длину передачи тела сообщения, если это не запрещается правилами в раздел 4.4 . Любая Довольная Длина, больше, чем или равный нулю, является допустимым значением.

Раздел 4.4 описывает, как определить длину тела сообщения, если Довольная Длина не дана.

, Таким образом, прокси-сервер не видит заголовок Довольной Длины, который он принимает, абсолютно необходим в HTTP 1.0, если существует тело. Таким образом, это принимает 0 так, чтобы запрос в конечном счете достиг сервера. Помните, что прокси не знает правил спецификации HTTP 1.1, таким образом, это не знает, как обработать ситуацию, когда нет никакого заголовка Довольной Длины.

Вы 100%, уверенных, что Ваш запрос определяет заголовок Довольной Длины? Если это будет использовать другое средство, как определено в разделе 4.4, потому что это думает, что сервер 1.1 (потому что это не знает об этих 1,0 промежуточных прокси), тогда, у Вас будет своя описанная проблема.

, Возможно, можно использовать HTTP, ДОБИРАЮТСЯ вместо этого для обхода проблемы.

Вы уверены, что эти запросы прибывают от "клиента"?

у меня была эта проблема с ботами прежде; они иногда зондируют сайты для, "связываются с нами" формы путем отправления пустых запросов POST на основе URI действия в Тегах form, которые они обнаруживают во время проверки.

В нашей системе есть клиент с точно такой же проблемой. Мы прикрепили его к прокси / брандмауэру. IAS Microsoft. Он удаляет тело POST и отправляет content-length: 0. Однако мы не очень много можем сделать, чтобы обойти это, и мы хотим использовать запросы GET, поскольку это раскрывает имена пользователей / пароли и т.д. в строке URL. В нашей системе почти 7000 пользователей, и только у одного возникла проблема ... и только один использует Microsoft IAS, так что это должно быть так.

Он удаляет тело POST и отправляет content-length: 0. Однако мы не очень много можем сделать, чтобы обойти это, и мы хотим использовать запросы GET, поскольку это раскрывает имена пользователей / пароли и т.д. в строке URL. В нашей системе почти 7000 пользователей, и только у одного возникла проблема ... и только один использует Microsoft IAS, так что это должно быть так.

Он удаляет тело POST и отправляет content-length: 0. Однако мы не очень много можем сделать, чтобы обойти это, и мы хотим использовать запросы GET, поскольку это раскрывает имена пользователей / пароли и т.д. в строке URL. В нашей системе почти 7000 пользователей, и только у одного возникла проблема ... и только один использует Microsoft IAS, так что это должно быть так.

Исправление Microsoft для KB821814 может установить Content-Length равным 0:

Исправление, описанное в этой статье, реализует изменение кода в Wininet.dll на:

• Обнаружить условие RESET в запросе POST.
• Сохранить данные, которые должны быть отправлены.
• Повторите запрос POST с длиной содержимого, установленной на 0. Это предотвращает выполнение сброса и позволяет завершить процесс аутентификации.
• Повторите исходный запрос POST.

Это легко воспроизвести с помощью MS-IE и фильтра проверки подлинности NTLM на стороне сервера. У меня такая же проблема с JCIFS (1.2. ), стойками 1. и MS-IE 6/7 на XP-SP2. Это было окончательно исправлено. Есть несколько обходных путей.

1. изменить метод формы с POST (настройка по умолчанию) на GET. Он подходит для большинства страниц с формами небольшого размера. К сожалению, у меня, возможно, более 50 записей для отправки в потоке HTTP обратно на сервер. IE имеет ограничение GET URL 2038 байт (не длина параметра, а полная длина URL). Так что это быстрое решение, но оно не применимо ко мне.

2. отправить GET перед выполнением действия POST. Это рекомендовалось в MS-KB. В моем проекте много устаревших процедур, и я бы не стал рисковать в нужный момент.Я никогда не пробовал этого, потому что он все еще требует дополнительной обработки аутентификации, когда GET получен слоем фильтра на основе моего понимания из MS-KB, и я не хотел бы изменять поведение с другими браузерами, например. Firefox, Opera.

3. определение того, был ли отправлен POST с нулевой длиной содержимого (вы можете получить его из хэш-структуры свойств заголовка в вашей платформе). Если да, запустите цикл проверки подлинности NTLM, получив код запроса от DC или кеша и ожидая ответа NTLM. Когда сообщение NTLM type2 получено и сеанс все еще действителен, вам действительно не нужно аутентифицировать пользователя, а просто перенаправить его ожидаемому действию, если длина содержимого POST не равна нулю. Кстати, это увеличило бы сетевой трафик. Поэтому проверьте настройки времени жизни кеша и настройку soTimeOut сеанса SMB перед применением изменения, пожалуйста. Или, что проще, вы можете просто отправить MS-IE статус 401-неавторизованный, и браузер отправит обратно POST-запрос с данные в ответ.

4. MS-KB предоставила исправление с помощью KB-923155 (я не смог опубликовать более одной ссылки из-за низкого номера репутации: {), но похоже, что это не работает. Мог бы кто-нибудь опубликовать здесь работоспособное исправление? Спасибо :) Вот ссылка для справки, http://www.websina.com/bugzero/kb/browser-ie.html

Если пользователь проходит через ISA proxy, который использует NTLM аутентификацию, то это похоже на эту проблему, у которой есть решение (патч для ISA proxy)

http://support.microsoft.com/kb/942638
POST запросы, не имеющие POST тела, могут быть отправлены на веб сервер, который опубликован в ISA Server 2006