Регулярное выражение Apache LocationMatch игнорирует повторяющиеся косые черты

У меня странное поведение с директивой Apache LocationMatch, когда в начале URL-адреса есть лишние косые черты. Согласно документам Apache, если я правильно читаю, это должно работать:

    <LocationMatch ^/appcontext/(a|b)>

            SetHandler weblogic-handler
            WebLogicCluster apphost01:xxxx,apphost02:xxxx
            WLProxySSL ON

    </LocationMatch>

Однако, если я ввожу следующий URL-адрес, он также перенаправляется на серверные хосты:

https:// ‹hostname:port› ////////appcontext/a/

В документах Apache четко указано, что директиву следует применять только для /appcontext/a/, если только я не упустил что-то с регулярным выражением или возникла какая-то проблема с подключаемым модулем mod_wl.

http://httpd.apache.org/docs/2.2/mod/core.html

"Например, ‹LocationMatch ^/abc› будет соответствовать URL-адресу запроса /abc, но не URL-адресу запроса //abc"

Есть ли у кого-нибудь предложения для достижения этого?


regex apache weblogic slash locationmatch
person jpt    schedule 18.09.2014    source источник
comment
^/appcontext/(a|b) также будет соответствовать ///appcontext/a/ (любому # из / до appcontext), поскольку они считаются избыточными косыми чертами. Какую проблему это вызывает?   -  person anubhava    schedule 18.09.2014
comment
Я могу ошибаться, но это даже не похоже на действительный URI. Часть после //, являющаяся ////////appcontext/a/, не является ни допустимым компонентом полномочий, ни допустимым путем (поскольку она начинается с // и не следует за полномочиями). tools.ietf.org/html/rfc3986#section-3   -  person Ryan M    schedule 18.09.2014
comment
У нас есть файл cookie с директивой Location для /appcontext/a, и браузер не считает косые черты излишними (он не отправляет файл cookie для ///appcontext/a/ только для /appcontext/a/)   -  person jpt    schedule 18.09.2014
comment
Тогда лучше перенаправить ////app на /app с помощью правила перезаписи.   -  person anubhava    schedule 18.09.2014
comment
Чтобы это оказало какое-либо влияние на клиентский браузер, вы имеете в виду правильное правило перенаправления? Насколько мне известно, правило перезаписи по-прежнему будет отображать неверный URL-адрес в браузере, и файл cookie не будет работать. Но если регулярное выражение не работает для LocationMatch, будет ли оно работать для RedirectMatch?   -  person jpt    schedule 18.09.2014
comment
Да, я имел в виду внешнее правило перенаправления в клиентском браузере.   -  person anubhava    schedule 18.09.2014
comment
@RyanM, извините, имя хоста: порт и LocationMatch были неверно истолкованы как теги HTML, исправлено.   -  person jpt    schedule 20.09.2014
comment
@anubhava попробовал RedirectMatch, но, похоже, он страдает от той же проблемы: RedirectMatch 302 ^//+ /appcontext/a/ Пробовал то же правило, но с ^/a+, и это сработало (/aaaa правильно перенаправил на /appcontext/a/) , кажется, Apache каким-то образом сворачивает лишние косые черты перед обработкой правил регулярных выражений   -  person jpt    schedule 20.09.2014

Ответы (1)


arrow_upward
1
arrow_downward

Да, Apache сворачивает лишние косые черты в правиле перезаписи. Вы можете использовать переменную THE_REQUEST для сопоставления и удаления лишних косых черт. Поместите это в корень .htaccess:

RewriteEngine On

RewriteCond %{REQUEST_URI} ^(.*?)//+(.*)$
RewriteRule ^ %1/%2 [R=302,L,NE]
person anubhava    schedule 20.09.2014
comment
К сожалению, мы не используем .htaccess, поскольку это виртуальный путь, однако я нашел аналогичный ответ в другом сообщении, который также работает внутри VirtualHost в файле .conf: stackoverflow.com/questions/11781237/ Я не смог проверить вашу версию, но я отмечу ответ как принятый, спасибо за ваше время. - person jpt; 20.09.2014
comment
Спасибо, что приняли это. Да, действительно, этот ответ будет работать в виртуальном пути. - person anubhava; 20.09.2014