Понимание 1 строки файла .htaccess - PullRequest
1 голос
/ 21 февраля 2011

У меня есть следующий .htaccess на данный момент. Здесь и там это пустышка, но я бы хотел немного больше узнать о том, что здесь происходит.

Итак, я хотел бы попросить вашей помощи, чтобы правильно прокомментировать эти инструкции .htaccess:

#1) The rewrite is probably on. Still, to make sure:
RewriteEngine On

#2) If we need to overwrite some server definitions:
#php_value upload_max_filesize 15M
#php_value post_max_size 15M
#php_value max_execution_time 200
#php_value max_input_time 200

#3) If we want to exclude some files from URI rewriting we do:
RewriteCond %{REQUEST_FILENAME} !^(filename1|filename2)

#4) If we want to exclude those directories from URI rewriting we do:
RewriteRule ^(dir1|dir2|dir3) - [L]

#5) What are we saying here ?
RewriteRule ^\.htaccess$ - [F]

#6) What does those lines mean ? How are those 3 Condition/Rule blocks related ?
RewriteCond %{REQUEST_URI} =""
RewriteRule ^.*$ /public/index.php [NC,L]

RewriteCond %{REQUEST_URI} !^/public/.*$
RewriteRule ^(.*)$ /public/$1

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.*$ - [NC,L]



#7) Should we have this, because it's somehow more controlled, OR should we use: !-f: ?
RewriteCond %{REQUEST_FILENAME} !\.(js|JS|Js|jS|ico|Ico|ICO|zip|ZIP|Zip|rar|RAR|Rar|mov|MOV|Mov|MPEG4|Mpeg4|mpeg4|mp4|Mp4|gif|GIF|Gif|jpg|JPG|Jpg|jpeg|JPEG|Jpeg|PNG|Png|png|CSS|Css|css|DOC|Doc|doc|PDF|Pdf|pdf|DOCX|Docx|DocX|docX|docx|WMV|Wmv|wmv|MPEG|Mpeg|mpeg|AVI|Avi|avi|MPG|Mpg|mpg|FLV|Flv|flv|PPT|Ppt|ppt|PPTX|PptX|Pptx|pptx|txt|TXT|txt)$

#8) Are we redirecting all requests inside public folder, to index.php ?
RewriteRule ^public/.*$ /public/index.php [NC,L]

Хотите прокомментировать / ответить на мои 1-8 комментариев?
Большое спасибо заранее.

ps - возможно, я должен разместить все эти вопросы на отдельных постах?

UPDATE: У меня много вопросов, которые я не могу понять. Когда мы не понимаем наших собственных вопросов, это плохой знак. На самом деле, лучше всего разбить все это на более мелкие части. Это, как говорится:

О пункте 3):

Итак, вот:

RewriteCond %{REQUEST_FILENAME} !^(filename1|filename2)

Сравниваем, скажем так:

/home/mysuser/public_html/something.php

с:

filename1 ИЛИ filename2

У нас есть ^, которые указывают нам на

«начало строки»

. Поскольку filename1 начинается не с /, а с

REQUEST_FILENAME

будет, это условие никогда не будет .

ОДНАКО, у нас есть !, который сводит на нет все.

Итак,

Мы сравниваем (опять, например):

/ дома / mysuser / public_html / something.php

с чем-то, что «не начинается с» (часть ^) / (поскольку в наших именах файлов не будет косой черты в начале), следовательно, условие all всегда будет иметь значение true.

Наличие условия, которое ВСЕГДА оценивает true или ВСЕГДА оценивает false, не так здорово Так что я верю. Тогда я лучше оставлю это.

ЕСЛИ ВСЕ ЭТИ ПРЕДПОЧТЕНИЯ ПРАВИЛЬНЫ И ТОЧНЫ: Три вопроса:

1) Кажется, что если мы каким-то образом сможем удалить часть ^ к чему-то, что соответствует всей строке, будет ли это предпочтительнее?

2) Есть ли другой способ сделать запрошенную вещь: «Что делать, если мы хотим исключить перенаправление некоторых файлов?»

3) Просматривая этот файл htaccess, я не могу понять: какое правило должно соответствовать этому условию?

Могу ли я получить вашу помощь, чтобы выяснить это?

Еще раз большое спасибо.

1 Ответ

1 голос
/ 23 февраля 2011
  1. RewriteEngine on всегда требуется для включения механизма перезаписи времени выполнения.
  2. Не имеет ничего общего с mod_rewrite.
  3. Это условие будет всегда истинным, так как значение REQUEST_FILENAME всегда начинается с /. Обратите внимание, что это абсолютный путь к файловой системе, а не путь URI (т. Е. REQUEST_URI ).
  4. Да, использование подстановки - не изменяет URI, но останавливает текущий процесс перезаписи в сочетании с флагом L . Обратите внимание, что шаблон будет соответствовать любому пути , который начинается с этих префиксов, а не только с каталогов.
  5. Это правило, вероятно, запрещает доступ к файлу .htaccess. Тем не менее, ваш веб-сервер уже должен покрывать это.
  6. Первое правило, вероятно, должно переписать внутренний запрос / на /public/index.php. Однако это правило никогда не будет применено, поскольку условие никогда не будет выполнено, поскольку REQUEST_URI никогда не пусто, но по крайней мере /. Второе правило будет делать то же самое для любого пути URI, если оно уже не начинается с /public/. И третье правило будет проходить через любой запрос, который может быть сопоставлен с существующим файлом.
  7. Этот список расширений имен файлов довольно обширный. Проблема в верхнем / нижнем регистре может быть решена с помощью флага NC . Но это правило не должно применяться к существующим файлам, так как предыдущее правило уже поймает его.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...