NGINX удалить Удалить расширение .html

Итак, я нашел ответ демонтажа расширения .html на моей странице, которая прекрасно работает с этим кодом:NGINX удалить Удалить расширение .html

server { 
    listen 80; 
    server_name _; 
    root /var/www/html/; 
    index index.html; 

    if (!-f "${request_filename}index.html") { 
     rewrite ^/(.*)/$ /$1 permanent; 
    } 

    if ($request_uri ~* "/index.html") { 
     rewrite (?i)^(.*)index\.html$ $1 permanent; 
    } 

    if ($request_uri ~* ".html") { 
     rewrite (?i)^(.*)/(.*)\.html $1/$2 permanent; 
    } 

    location/{ 
     try_files $uri.html $uri $uri/ /index.html; 
    } 
}

Но если я открываю mypage.com он перенаправляет меня mypage.com/index
Не было ли это исправлено, объявив index.html в качестве индекса? Любая помощь приветствуется.

источник

2016-07-06 SkyGuardian42

ОБНОВЛЕННЫЙ ОТВЕТ: Этот вопрос вызвал мое любопытство, и я продолжил еще один, более углубленный поиск решения «святого грааля» для перенаправления .html в Nginx. Вот ссылка на ответ, который я нашел, так как сам не придумал: https://stackoverflow.com/a/32966347/4175718

Однако я приведу пример и объясню, как это работает. Вот код:

location/{ 
    if ($request_uri ~ ^/(.*)\.html$) { 
     return 302 /$1; 
    } 
    try_files $uri $uri.html $uri/ =404; 
}

То, что здесь происходит довольно остроумное использование if директивы. Nginx запускает регулярное выражение в части входящих запросов $request_uri. Регулярное выражение проверяет, имеет ли URI расширение .html, а затем сохраняет часть URI без расширения во встроенной переменной $1.

С docs, так как мне потребовалось некоторое время, чтобы выяснить, где $1 пришли:

Регулярные выражения могут содержать снимки, которые доступны для дальнейшего использования в $ 1 .. $ 9 переменных.

Регулярное выражение проверяет наличие нежелательных .html-запросов и эффективно унижает URI, чтобы оно не включало расширение. Затем, используя простой оператор return, запрос перенаправляется на дезинфицированный URI, который теперь хранится в $1.

Большая часть об этом, как оригинальный автор cnst объясняет, что

В связи с тем, что $ REQUEST_URI всегда постоянна для каждого запроса, и не зависит от других переписывает, он не будет, фактически, образуют любые бесконечные петли.

В отличие от перезаписи, которые работают на любой.html запрос (в том числе невидимого внутреннего перенаправления к /index.html), это решение работает только на внешних URI, которые видны пользователю.

Вам все равно понадобится директива try_files, так как в противном случае Nginx не будет знать, что делать с новыми дезинфицированными URI без расширения. Директива try_files работает так:

Nginx будет первым добавить .html в конце URI и пытаются обслуживать его. Если он найдет соответствующий файл .html, он вернет этот файл и сохранит URI без расширения. Если он не может найти подходящий файл .html, он попробует URI без какого-либо расширения, затем URI в качестве каталога, а затем, наконец, вернет ошибку 404.

Обратите внимание, что это считается безопасным использование в if директивы, на странице Nginx Если ЗЛО:

только 100% безопасные вещи, которые могут быть сделаны внутри, если в месте контекст:

возвращение ...;

rewrite ... last;

источник

2016-07-07 05:20:28 Arnon

Каким образом использовать переадресацию 302 вместо 301? – WillB

@WillB Поскольку 301 переадресация кэшируется браузерами, мне нравится использовать 302, если я не уверен на 100%, что я никогда не хочу отменять перенаправление. Из того, что я видел, Google, похоже, не слишком заботится, и это делает его намного проще, если в один прекрасный день вы решите, что хотите вернуться к расширению .html в своих URL-адресах. – Arnon

инструкция try_files должна выйти за пределы блока if ... – goliatone

Это часто придумывает для меня, а также и из-за конфигурации на работе, блоки определения местоположения ненадежные в лучшем случае и/& .php блоки заблокированы. Это означает, что большинство решений не работают для меня.

Итак, вот что я упростил из принятого ответа выше.

rewrite ^/(.*)\.html /$1/ permanent;

Работает отлично подходит для КМПА, где основной каркас генерирующих страниц

источник

2017-09-12 01:01:34 user1270949

Я считаю, что проблема, с которой я столкнулся с методом перезаписи, заключалась в том, что /index.html будет перенаправлен на/index. Это либо вызвало бесконечный цикл, либо привело к тому, что целевая страница стала www.example.com/index. – Arnon

NGINX удалить Удалить расширение .html

ответ

Смежные вопросы