Comments 19
А кто ему посылает http/1.0 запрос? Приличные люди так не делают.
А что, http/1.0 отменили? Он юзается до сих пор, и очень интенсивно. Так что вопрос не в том, кто посылает, а в том, какого хрена php-код криво отвечает. Так что и Ваш вопрос, и Ваш минус не в тему абсолютно.
Не отменили, но принудительно отвечать на все запросы 1.0 ответом — тоже не дело.
А вот разобраться с причиной проблемы, а не делать кривой костыль — это была бы хорошая статья.
P.S. а минус не мой.
А вот разобраться с причиной проблемы, а не делать кривой костыль — это была бы хорошая статья.
P.S. а минус не мой.
Согласно спецификации, на запрос HTTP/1.0 отвечать надо той же версией протокола, HTTP/1.0. Может клиентская сторона и вовсе HTTP/1.1 не поддерживает, потому HTTP/1.0 и запрашивала.
Причина проблемы выяснена — php-код кривой. По-хорошему его править и надо. Но править код постоянно обновляемого друпала — не вариант.
При этом посмотрел логи — HTTP/1.1 всё равно работает. Так что сакральный смысл настройки BrowserMatch у апача остаётся неясным.
Причина проблемы выяснена — php-код кривой. По-хорошему его править и надо. Но править код постоянно обновляемого друпала — не вариант.
При этом посмотрел логи — HTTP/1.1 всё равно работает. Так что сакральный смысл настройки BrowserMatch у апача остаётся неясным.
PHP-код отвечат абсолютно верно и нормально. Это известная проблема именно nginx-а при выполнении 3-х условий:
1) код ответа 404,
2) версия протокола HTTP/1.1,
3) размер тела ответа болье некого значения Х (я просто не помню сейчас точно это значение, но оно константно).
Это раз. Во-вторых, проблема легко решается просто выдачей ответа из PHP заголовком: «header(»HTTP/1.0 404 Not Found");" вместо «header(»HTTP/1.1 404 Not Found");". Этого абсолютно достаточно, и не важно в каком протоколе идет запрос от пользователя.
1) код ответа 404,
2) версия протокола HTTP/1.1,
3) размер тела ответа болье некого значения Х (я просто не помню сейчас точно это значение, но оно константно).
Это раз. Во-вторых, проблема легко решается просто выдачей ответа из PHP заголовком: «header(»HTTP/1.0 404 Not Found");" вместо «header(»HTTP/1.1 404 Not Found");". Этого абсолютно достаточно, и не важно в каком протоколе идет запрос от пользователя.
тоже встречался с этим, щас не помню как разруливал… кажется, просто переводил клиента с жиксы на сквид
А где именно в коде ошибка напишите пожалуйста, чтоб можно было посмотреть/поправить.
Вот здесь смотрите код функции drupal_not_found
api.drupal.org/api/function/drupal_not_found/6
Там жётско прописано «drupal_set_header('HTTP/1.1 404 Not Found');».
Как фиксить не в курсе — я в php не силён.
api.drupal.org/api/function/drupal_not_found/6
Там жётско прописано «drupal_set_header('HTTP/1.1 404 Not Found');».
Как фиксить не в курсе — я в php не силён.
Дело совсем не в Друпале. Поиском по гуглу пользоваться не умеете? Ищите по фразе «nginx цифры вверху страницы».
Вот как раз ваш случай (Да и мой тоже. )) ).
Попробовал убрать «BrowserMatch ».*" downgrade-1.0 force-response-1.0" и отключить Keep-Alive. Проблема снова проявилась. Вернул BrowserMatch обратно.
Так что случай не мой.
Так что случай не мой.
Я вам всего лишь написал, что Друпал тут совершенно не при чем.
См. коммент выше. Друпал вызывает жёстко drupal_set_header('HTTP/1.1 404 Not Found'); на 404-ю ошибку. Так что дело в друпале, в его коде. Другой вопрос, что проявляется проблема только в связке nginx с apache.
Если неизвестен заголовок «Content-Length» (для HTTP/1.1) Apache передаёт ответ чанками (chunks) и добавляет заголовок «Transfer-Encoding: chunked».
Решается в PHP так:
header($_SERVER['SERVER_PROTOCOL'].' 200 OK');
header($_SERVER['SERVER_PROTOCOL'].' 404 Not Found');
Или в Apache так:
SetEnv force-no-vary
SetEnv downgrade-1.0
Решается в PHP так:
header($_SERVER['SERVER_PROTOCOL'].' 200 OK');
header($_SERVER['SERVER_PROTOCOL'].' 404 Not Found');
Или в Apache так:
SetEnv force-no-vary
SetEnv downgrade-1.0
Спустя два года — очень кстати совет :). Спасибо.
Sign up to leave a comment.
nginx и непонятные цифры перед