Вопрос по динамическому разбору URL

Question

Я вижу много-много сайтов, у которых есть URL-адреса для отдельных страниц, например

http://www.mysite.com/articles/this-is-article-1 http://www.mysite.com/galleries/575

И они не перенаправляют, они не бегут медленно ...

Я знаю, как разбирать URL, это достаточно просто. Но на мой взгляд, это кажется медленным и громоздким на динамическом сайте. Кроме того, если все страницы статически построены (за исключением пользовательского URL), это означает, что все компоненты страницы также являются статическими ... (что было бы плохо)

Я бы хотел услышать некоторые идеи о том, как это обычно достигается.

Answer 1

Есть много способов справиться с вышеизложенным. Вообще говоря, всегда есть какая-то форма перенаправления, хотя это может быть на уровне .htaccess, а не php. Вот сценарий:

1. Используйте .htaccess для перенаправления в ваш скрипт обработки php.

2. Разбор uri ($ _SERVER ['REQUEST_URI']) и определение типа контента (например, статей или галерей в соответствии с вашими примерами).

3. Используйте предоставленный идентификатор (обычно добавляемый в конец URI, опять же, как в ваших примерах), чтобы получить правильные данные - будь то путем предоставления статического файла или запроса базы данных для запрошенного содержимого.

Этот метод является очень популярным способом увеличения SEO, но, как вы правильно заметили, при таком подходе могут возникнуть трудности - обычно это не производительность, но это может сделать разработку или администрирование более проблематичным (чем позже, если ваша реализация не очень хорошо работает) продуманный и масштабируемый).

Answer 2

Во-первых, при сравнении / plain / перезаписи URL-адресов на уровне приложения с использованием / plain / CGI (CGI может быть PHP, ISAPI, ASP.NET и т. Д.) С обслуживанием статических страниц, обслуживание статических файлов всегда будет всегда выигрывать , Там просто меньше работы. Например, в Windows и Linux (о которых я знаю) в ядре даже есть усовершенствования для обслуживания статических файлов на локальном диске через HTTP. Чтобы еще больше подчеркнуть, я даже нашел эталонный тест с использованием нескольких серверов и операционных систем: http://www.litespeedtech.com/web-server-performance-comparison-litespeed-2.0-vs.html#RESULT Обратите внимание, что обслуживание статических файлов значительно быстрее, чем при использовании любого типа CGI

Однако при эффективном использовании переписанных URL-адресов возможны выигрыши в производительности и масштабируемости, и это делается с помощью кэширования. Если вы вернете правильные заголовки кеша (см. Директиву cache-control в документации HTTP ), то это позволит нижестоящим серверам кэшировать данные, чтобы вы даже не попали на ваш сайт. Однако, я думаю, вы могли бы получить то же преимущество со статическими страницами :) Я случайно прочитал статью на эту же тему день или два назад в блоге High Scalability: http://highscalability.com/strategy-understanding-your-data-leads-best-scalability-solutions

Answer 3

Лучше всего переписать движок, так как он быстрый и оптимизированный. Разрешение вашим серверным сценариям использовать только простые локальные переменные.

Apache mod_rewrite является наиболее распространенным.

Answer 4

Обычно это делается через механизм перезаписи , либо на сервере (через что-то вроде mod_rewrite в Apache), либо в веб-приложении (все запросы направляются в веб-приложение, которое ищет маршрут для путь указан).

Answer 5

Я использовал этот метод предварительно - вам просто нужно добавить расширения файлов, которые не должны перенаправляться в регулярное выражение, а затем все остальное обрабатывается php, поэтому вам не нужно заходить в ваш файл .htacces

с URL-адресами

Answer 6

На серверах apache mod_rewrite является наиболее распространенным для этого, это мод apache, который позволяет вам переписывать URL-адреса запросов на другие URL-адреса с помощью регулярных выражений, поэтому для вашего примера будет использовано что-то вроде этого:

RewriteEngine ON
RewriteRule ^articles/(.*) articles.php?article=$1 [L]
RewriteRule ^galleries/(\d*) galleries.php?gallerie=$1 [L]

Это вряд ли стоит времени, и на практике это так же быстро, как и URL:
www.mysite.com/galleries.php?gallerie=575, но выглядит лучше

Answer 7

Очень простой способ - заставить CGI анализировать часть URL-адреса PATH_INFO. В вашем примере:

http://www.example.com/articles/12345 (where "articles" is a CGI script)
                       ^CGI^   ^^^^^^PATH_INFO

Каждая вещь после имени скрипта передается скрипту в заголовке CGI PATH_INFO.

Затем вы можете выполнить поиск в базе данных или что угодно, чтобы создать страницу.

Будьте осторожны при доступе к этому значению, поскольку сервер IIS и сервер Apache помещают разные части URL-адреса в PATH_INFO. (IIRC: IIS неправильно использует весь URL-адрес, и Apache удаляет его, как указано выше.)

Answer 8

Можно переписать на

1. Уровень сервера в файле .htaccess или в файле httpd.conf или vhosts.conf. Обычно это быстрее, чем следующий уровень перезаписи, который выполняется на уровне приложения.

2. Уровень приложения (в данном случае с PHP). Вы можете написать собственные перенаправления, которые анализируют URL и каким-то образом перенаправляют на основе этого. Современные веб-фреймворки, такие как Zend Framework (ZF), используют маршруты для управления перезаписью URL. Ниже приведен пример статического маршрута с ZF

$ route = new Zend_Controller_Router_Route_Static ('последние / новости / эта / неделя', массив ('controller' => 'news'));

Что перенаправит любой запрос из http://somedomain.com/lastest/news/this/week в контроллер новостей.

Примером динамического маршрута будет

$ route = new Zend_Controller_Router_Route ('galleries /: id', массив ('controller' => 'gallery'));

Где переменная $ id будет доступна для этого контроллера (и в нашем примере выше будет 575)

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

Answer 9

В моем случае я придерживаюсь веб-фреймворка с этой встроенной функцией. (CodeIgniter)

... Также, если все страницы статичны встроенный (потом пользовательский URL) то означает, что все компоненты страницы статично ... (что было бы плохо)

... да, это действительно очень плохо. : О