Re: internal и allow/deny

[Роман Маширов <mrj@xxxxxxxx>]

Игорь, спасибо!

Правильно ли я понимаю, в таком случае можно ограничиться allow 127.0.0.1 deny all, без internal, если не нужно скрывать от посетителя сам факт существования /block?

И еще, пользуясь случаем -- по поводу 304 not modified и x-accel-redirect -- в итоге не существует способа отключить проверку файла по if-modified-since?

Igor Sysoev wrote:

On Mon, Feb 09, 2009 at 02:51:51PM +0300, Роман Маширов wrote:

  

Добрый день!

Есть location, из которого отдаются закешированные файлы в ssi. Если 
файла нет, запрашиваем бэк:

       location /block {
           root /.../cache_back;

           error_page   404  =  @fallback;
           log_not_found off;
       }

Далее, блоки показывать пришедшим снаружи не хочу, поэтому добавляю 
internal. В результате все запросы снаружи на /block ломятся на бэк. 
Поведение соответствует документации, но не здравому смыслу...

       location /block {
           root /.../cache_back;

           error_page   404  =  @fallback;
           internal;
           log_not_found off;
       }

Если запретить доступ для всех, кроме самого фронта:

       location /block {
           root /.../cache_back;

           error_page   404  =  @fallback;
           internal;
           allow 127.0.0.1;
           deny all;
           log_not_found off;
       }

Получаю еще более странную штуку -- запросы все равно ломятся на бэк. По 
всей видимости internal имеет более высокий приоритет чем allow/deny? Я 
что-то упустил, или internal в таком случае неприменим? Может логичнее 
было бы отдавать 403 на internal а не 404?
    

internal отрабатывает раньше allow/deny.

403 говорит, что на сервере такой location существует, а 404 полностью
скрывает от клиента существование location'а.

Решить проблему можно с помощью try_files:

     location /block {
        internal;
        try_files  $uri  @fallback;
     }