Почему «Content-Length: 0» в запросах POST?

Question

Клиент иногда отправляет запросы POST с Content-Length: 0 при отправке формы (от 10 до более 40 полей).

Мы протестировали его в разных браузерах и в разных местах, но не смогли воспроизвести ошибку. Клиент использует Internet Explorer 7 и прокси.

Мы попросили их позволить системному администратору разобраться в проблеме со своей стороны. Запуск некоторых тестов без прокси и т. Д.

Тем временем (через полгода и до сих пор нет ответа) мне любопытно, знает ли кто-нибудь еще о подобных проблемах с запросом Content-Length: 0. Может быть, из какой-то сети Windows со специальным прокси для крупных компаний.

Известна ли проблема с Internet Explorer 7? С прокси системой? Сама сеть Windows?

Google показал что-то только в контексте аутентификации NTLM (и тому подобное), но мы не используем это в веб-приложении. Может быть, дело в том, как прокси работает в сети клиента с логинами Windows? (Я не эксперт по Windows. Просто думаю.)

У меня нет дополнительной информации об инфраструктуре.

ОБНОВЛЕНИЕ: В декабре 2010 года об этом можно было сообщить одному администратору, в т.ч. ссылки из ответов здесь. Контакт был из-за другой проблемы, которая также была вызвана прокси. Нет отзывов с тех пор. И сообщения об ошибках все еще там. Я смеюсь, чтобы помешать мне плакать.

ОБНОВЛЕНИЕ 2: Эта проблема существует с середины 2008 года. Каждые несколько месяцев клиент раздражен и хочет, чтобы это было исправлено как можно скорее. Мы снова отправляем им все старые электронные письма и просим их связаться с их администраторами, чтобы либо исправить это, либо провести дополнительные тесты. В декабре 2010 года мы смогли отправить некоторую информацию одному администратору. Нет отзывов. Проблема не устранена, и мы даже не знаем, пытались ли они. А в мае 2011 года клиент снова пишет и хочет, чтобы это было исправлено. Тот же человек, который имеет всю информацию с 2008 года.

Спасибо за все ответы. Вы помогли многим людям, как я вижу из некоторых комментариев здесь. Жаль, что реальный мир - это гротеск для меня.

ОБНОВЛЕНИЕ 3: Май 2012 года, и мне было интересно, почему мы не получили еще одно требование исправить это (см. ОБНОВЛЕНИЕ 2). Изучил протокол ошибок, который только сообщает об этой единственной ошибке каждый раз, когда она произошла (около 15 в день). Это прекратилось в конце января 2012 года. Никто ничего не сказал. Должно быть, они что-то сделали со своей сетью. Уже все хорошо. С лета 2008 года по январь 2012 года. Жаль, что я не могу рассказать вам, что они сделали.

ОБНОВЛЕНИЕ 4: Сентябрь 2015. Веб-сайт должен был собрать некоторые данные и доставить их на основной веб-сайт клиента. Был API с аккаунтом. Всякий раз, когда возникала проблема, они связывались с нами, даже если проблема явно была на другой стороне. Уже несколько недель мы не можем отправить им данные. Аккаунт больше не доступен. У них был перезапуск, и я больше не могу найти страницы, которые использовали данные нашего сайта. В отчете об ошибке нет ответа и никто не жалуется. Я думаю, они только что закончили этот проект.

ОБНОВЛЕНИЕ 5: Март 2017 года. API перестал работать летом 2015 года. Похоже, что клиент продолжает платить за сайт и все еще получает доступ к нему в феврале 2017 года. Я предполагаю, что они используют его как архив Они больше не создают и не обновляют данные, поэтому эта ошибка, вероятно, не возникнет после таинственного исправления в январе 2012 года. Но это будет чья-то проблема. Я ухожу.

Answer 1

У нас был клиент, использующий один и тот же веб-сайт в анонимном режиме и в режиме NTLM (на разных портах). Мы обнаружили, что в нашем случае 401 был связан с приложением Riverbed Steelhead, используемым для оптимизации http. Первым сигналом, указывающим нас в этом направлении, был заголовок X-RBT-Optimized-By. Проблема была в бесплатной функции 401:

Эта функция может использоваться как для запроса, так и для подключения аутентификация, но она наиболее эффективна при использовании с запросом аутентификация. При аутентификации по запросу каждый запрос должен быть аутентифицироваться на сервере, прежде чем сервер будет обслуживать возразить клиенту. Однако большинство браузеров не кэшируют сервер ответ требует аутентификации и, следовательно, он будет тратить один туда и обратно для каждого запроса GET. С Gratuitous 401, на стороне клиента Устройство Steelhead будет кэшировать ответ сервера и когда клиент отправляет запрос GET без каких-либо заголовков аутентификации, он будет локально ответить сообщением «401 Unauthorized» и, следовательно, сохранить поездка туда и обратно. Обратите внимание, что модуль HTTP не участвует в Сама актуальная аутентификация. Что модуль HTTP делает, чтобы сообщить клиент, которому сервер требует аутентификацию, не требуя это впустую один раунд.

Answer 2

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

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

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

Answer 3

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