Custom Query (2297 matches)

Во всех актуальных версиях nginx (проверял на 1.4.x и 1.5.x) наблюдается ситуация с не правильным парсингом расширения файла при отсутствии названия файла (имя файла до точки), что приводит к установке дефолтного Content-Type содержимого. С одной стороны это не столь значимо, но порой вынуждает разработчиков городить костыли вокруг этой особенности, т.к. при отсутствии правильного Content-Type и включенного mime-сниффинга в Internet Explorer существует риск XSS нападения, например, через загрузку вполне валидной (по мнению PHP) картинки. Разумеется, мы всем рекомендуем выставлять соответствующий заголовок вне зависимости от контекста приложения и используемого веб-сервера, но слушаются далеко не все:-(

Имеем стандартную конфигурацию и два файла: .jpg и test.jpg Ожидаемый результат при обращении к ним:

$ http -h http://localhost:8081/test.jpg
HTTP/1.1 200 OK
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 5
Content-Type: image/jpeg
Date: Tue, 11 Mar 2014 12:51:53 GMT
ETag: "531f00c1-5"
Last-Modified: Tue, 11 Mar 2014 12:25:37 GMT
Server: nginx/1.5.12


$ http -h http://localhost:8081/.jpg    
HTTP/1.1 200 OK
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 5
Content-Type: image/jpeg
Date: Tue, 11 Mar 2014 12:51:56 GMT
ETag: "531f00c1-5"
Last-Modified: Tue, 11 Mar 2014 12:25:37 GMT
Server: nginx/1.5.12

Актуальный:

$ http -h http://localhost:8081/test.jpg
HTTP/1.1 200 OK
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 5
Content-Type: image/jpeg
Date: Tue, 11 Mar 2014 12:54:46 GMT
ETag: "531f00c1-5"
Last-Modified: Tue, 11 Mar 2014 12:25:37 GMT
Server: nginx/1.5.12


$ http -h http://localhost:8081/.jpg    
HTTP/1.1 200 OK
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 5
Content-Type: application/octet-stream
Date: Tue, 11 Mar 2014 12:54:48 GMT
ETag: "531f00c1-5"
Last-Modified: Tue, 11 Mar 2014 12:25:37 GMT
Server: nginx/1.5.12

Имеется конфигурация сервера. Вот две его части:

location = / { proxy_cache cache_page; proxy_cache_key $scheme$host; proxy_cache_valid 1m;

proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504 http_404;

proxy_pass ​http://127.0.0.1:8280; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $http_host; proxy_redirect default; proxy_buffering on; }

location = /carDescription.htm { proxy_cache cache_page; proxy_cache_key $scheme$host$request_uri; proxy_cache_valid 15s;

proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504 http_404;

proxy_pass ​http://127.0.0.1:8280; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $http_host; proxy_redirect default; proxy_buffering on; }

Как видно, разницы практически никакой. Оба параметра: proxy_cache_bypass и proxy_no_cache не прописаны вообще нигде. Тоесть посути должны кэшироваться оба локэйшена. Но корневая страница не кэшируется и не возвращается при отключенном бакэнде. в отличие от carDescription.html

Прописывание фейковых proxy_cache_bypass и proxy_no_cache проблему не решает. Не можем запустить fail-safe конфигурацию из-за этого бага.

Хелп плиз! Спасибо.

При наличии вот такого тестового правила:

location ~ ^/testifmod/
        {
                if ($http_if_modified_s != '')
                {
                        return 503;
                }
                if ($http_if_modified_since != '')
                {
                        return 503;
                }
        }

Делаю запрос:

wget -d --header="If-Modified-S: Mon, 21 Apr 2014 11:37:49 GMT" ​http://mysite/testifmod/ Выдаёт ошибку 503, гуд.

Делаю запрос: wget -d --header="If-Modified-Since: Mon, 21 Apr 2014 11:37:49 GMT" ​http://mysite/testifmod/ Не выдаёт 503! Как так?