Назад | Перейти на главную страницу

Мод - Проблема Rewrite / .htaccess с Apache 2.4.12

Файловая структура выглядит следующим образом

Что я хотел бы сделать, так это преобразовать приведенный ниже код из Apache 1.3.42 в файл Apache 2.4.12 .htaccess, похоже, несколько изменений во время пути SSL - это то, на чем я действительно зацикливаюсь.

Когда вы пробуете любой документ с путем SSL, все, что я вижу, если путь _private, а не путь public_html в источнике HTML для любых типов файлов, таких как CSS, js-изображения и т. Д.

У меня также есть проблемы с разрешениями, которые просят меня войти в систему в режиме SSL, это должно быть связано с одним из других .htaccess файлы. Это должно быть просто, но почему-то я еще не понял правила правильно.

Вот строки кода в каждом файле .htaccess.

Публичные файлы: / home / usrname / public_html

RewriteEngine On

RewriteCond %{HTTP_HOST} ^99\.00\.99\.000$
RewriteRule ^/?(.*)$ http://www.example.com/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^example.com$
RewriteRule ^/?(.*)$ http://www.example.com/$1 [R=301,L]

RewriteCond /home/usrname/public_html/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /home/usrname/public_html/$1 [L]
RewriteCond /home/usrname/public_html/_private/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /home/usrname/public_html/_private/$1 [L]
RewriteRule ^(.+) - [PT]

DirectoryIndex home.html index.htm index.html default.htm Default.htm
Action cgi-ccd /cgi-bin/aws.emp
AddHandler cgi-ccd html
AddHandler default-handler .gif
AddHandler default-handler .jpg

<FilesMatch "\.(inx|weo|lco|dbo|cdo|fpo|dao)">
Order Allow,Deny
Allow from env=local_ref
</FilesMatch>

<Files 403.shtml>
order allow,deny
allow from all
</Files>

У нас также есть эти .htaccess файлы в учетной записи по их соответствующим путям.

Личные файлы: / home / usrname / public_html / _private

AuthUserFile .htpasswd
AuthGroupFile /dev/null
AuthName Administrator
AuthType Basic
<limit GET>
require valid-user
</limit>

Базы данных: / home / usrname / public_html / _private / data

AuthUserFile .htpasswd
AuthGroupFile /dev/null
AuthName Administrator
AuthType Basic
<limit GET>
require valid-user
</limit>

CGI BIN: / home / usrname / public_html / cgi-bin

Options +ExecCGI
Order allow,deny
Allow from all

Возможно, есть что-то в том, как все это работает вместе, что сейчас является проблемой в Apache 2.4+? Может дело в разрешениях на вызов файла из каталога CGI-BIN, при необходимости могу переместить?

Редирект 301 довольно прост, кажется. Синтаксис, возможно, потребуется изменить для версии, но они кажутся достаточно простыми для программирования. Я думаю, что есть некоторый конфликт с чем-то вроде Options FollowSymLinks SymLinksIfOwnerMatch ExecCGI Includes MultiViews или некоторой другой комбинации; Я безуспешно пробовал несколько комбинаций.

В конце концов, все, что я пытаюсь сделать, замаскировать полный путь cgi-bin пути программного обеспечения, но предоставить старый путь обратно как 301 редирект, чтобы мы не теряли ссылки, которые могут быть проиндексированы или добавлены в закладки.

. т.е.

From: http://www.example.com/cgi-bin/aws.emp/any-document-file-name.html
To: http://www.example.com/any-document-file-name.html

или в режиме SSL.

From: https://www.example.com/cgi-bin/aws.emp/any-document-file-name.html
To: https://www.example.com/any-document-file-name.html

Я обнаружил, если я изменю следующее с %{REQUEST_FILENAME} к %{REQUEST_URI} это, по крайней мере, позволяет всему работать, если вам не нужен путь SSL, затем он показывает путь _private для любых типов файлов, таких как css, js, изображения и т. д.

Надеюсь, я предоставил достаточно информации, чтобы помочь решить эту досадную проблему, но, к сожалению, у меня нет опыта работы с mod_rewrites, и поэтому сейчас это похоже на черную магию. На решение простых приличных вещей могут уйти недели.

Любая помощь приветствуется, я так хочу перейти с Apache 1.3.42, так как это уже давно назрело, и как только эта проблема будет решена, я смогу.

Я обнаружил, если я изменю следующее с %{REQUEST_FILENAME} к %{REQUEST_URI} это хотя бы позволяет всему работать

Если этим вы имеете в виду следующий блок кода (предположительно в корне .htaccess файл):

RewriteCond /home/usrname/public_html/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /home/usrname/public_html/$1 [L]
RewriteCond /home/usrname/public_html/_private/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /home/usrname/public_html/_private/$1 [L]
RewriteRule ^(.+) - [PT]

Тогда это имеет лишь небольшой смысл. Проблема в том, что эти директивы не работали бы и на Apache 1.3, если бы они использовались в .htaccess.

"Проблема" в том, что содержание этого .htaccess файл выглядит так, как будто он был взят прямо из конфигурации сервера. В .htaccess контексту эти директивы никогда не будут соответствовать, независимо от того, REQUEST_FILENAME был изменен на REQUEST_URI. При использовании в конфигурации сервера REQUEST_FILENAME такой же как REQUEST_URI, но в .htaccess REQUEST_FILENAME - это абсолютный путь к файловой системе, которому соответствует запрос. Итак, используя REQUEST_URI в этом контексте это просто «менее неправильно», это все равно неправильно.

Перезапись на /home/usrname/public_html/... (абсолютный путь к файловой системе) недопустим в .htaccess. В случае успешного выполнения это приведет к ошибке 400 Bad Request.

Однако на самом деле эти директивы не выглядят так, как будто они что-то делают. Они просто перезаписывают запрос обратно в тот же файл - что не имеет особого смысла - так что трудно понять, в чем заключаются намерения этих директив? Возможно, они предназначены для остановки выполнения других директив (например, для предотвращения передачи запросов в сценарий CGI)?

некоторый конфликт с чем-то вроде Options FollowSymLinks SymLinksIfOwnerMatch ExecCGI Includes MultiViews

Тебе понадобиться FollowSymLinks или SymLinksIfOwnerMatch установлен для работы mod_rewrite. И вам может потребоваться отключить MultiViews.