rewrite url rules, чтобы удалить внешний вид подкаталога в файле asp.net web.config

Question

У меня есть домен, который размещен на сайте discountasp.net (стандартный .net веб-хост). Позвоните по номеру http://example.com.

В домене размещен веб-сайт по умолчанию, а также несколько отдельных веб-приложений.

Веб-сайт создан в Wordpress, и он живет в подкаталоге/wordpress корневого каталога домена на хосте.

Я хочу сделать так, чтобы в URL-адресе, который пользователь видит в браузере, нет/wordpress. Раньше в корневой каталог был файл index.html, который перенаправлял запросы для http://example.com/ на http://example.com/wordpress/. Но это, конечно, просто перенаправление и оставляет http://example.com/wordpress/ в строке URL браузера.

Я думал, что смогу добиться того, что я хотел, с правилами перезаписи URL в моем файле Web.config в корневом каталоге. Ниже приведен текст этого файла.

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
    <system.webServer> 
    <rewrite> 
     <rules> 
      <rule name="wordpress redirect a"> 
       <match url="wordpress/(.*)"/> 
       <action type="Rewrite" url="{R:1}"/> 
      </rule> 
      <rule name="wordpress redirect b"> 
       <match url=".*"/> 
       <conditions> 
        <add input="{REQUEST_URI}" pattern=".*nm.*" matchType="Pattern" negate="true" ignoreCase="false"/> 
        <add input="{REQUEST_URI}" pattern=".*survey.*" matchType="Pattern" negate="true" ignoreCase="false"/> 
       </conditions> 
       <action type="Rewrite" url="wordpress/{R:0}"/> 
      </rule> 
     </rules> 
    </rewrite> 
    </system.webServer> 
</configuration> 

Логика файла:

• Первое правило: если путь URL (часть после того, как хост: порт /) начинается с wordpress/, он удаляет wordpress/ и продолжает обработку правил только с той части, которая появилась после wordpress/.

• Второе правило: для любого URL-адреса, который не содержит специальные строки веб-приложения «nm» или «обзор», поместите wordpress/ впереди на пути.

Это работает, в том смысле, что если я ставлю http://example.com/ в строке браузера, он показывает веб-сайт правильно, а также это переписывание не мешает вызовов веб-приложений, таких как http://example.com/nm/ ...

Тем не менее, он по-прежнему оставляет/wordpress в URL-адресе, который видит пользователь (т. Е. Когда я помещаю в панель браузера, в итоге я заканчиваю с http://example.com/wordpress/ в строке браузера после того, как он переписывает/перенаправляет его. Возможно, это Я просто не понимаю, что делают правила перезаписи. Но мое понимание (и то, что я пытался достичь с помощью этих правил), заключалось в том, что любой inc URL-адрес oming (кроме моих специальных URL веб-приложений), который не включает wordpress/, будет обрабатываться внутренне, как если бы он включал /wordpress, но затем возвращался клиенту в качестве исходного URL-адреса, не включая /wordpress. Итак, не переадресация, а лишь некоторая внутренняя ошибка. И тогда первое правило существует потому, что ссылки на веб-сайте будут включать /wordpress, и поскольку я не хочу получать /wordpress/wordpress, мне нужно снять его перед добавлением.

Но, очевидно, я что-то не понимаю.

Другая подсказка заключается в том, что второе правило, похоже, не выполняет свою работу, когда я использую URL-адрес http://example.com/about/. Второе правило должно сделать так, как если бы оно было http://example.com/wordpress/about/, но вместо этого я получил ошибку 404, не найденную. Но если я поместил http://example.com/wordpress/about/ в панель браузера, он правильно отобразит веб-страницу. Поэтому я смущен.

Answer 1

Чтобы ответить на мой собственный вопрос, по крайней мере, частично:

1. Вам не придется беспокоиться о правилах перезаписи Web.config URL-адрес портя URLs веб-приложений. Если сопоставление URL-адресов ведет к веб-приложению, ASP.net не будет применять правила перезаписи URL-адреса Web.config «по пути» (например, если Web.config находится в вашем корневом каталоге), но будет использовать URL-адреса веб-приложения как -является.

2. Панель управления администратора Wordpress под «общими настройками» имеет возможность установки как физического каталога ваших файлов Wordpress, так и «виртуального» каталога того, как URL-адреса должны отображаться пользователю. Лучше использовать эти параметры, потому что попытка «подделать» wordpress своими собственными переадресациями сложна.