Я немного запутался, как работают URL. В старые времена, когда я изучал HTML и прочее, я знал, что после имени домена находится местоположение файла, который мы хотим загрузить (например, website.com/somefolder/somefile.html). И это было просто, я мог это понять.

Недавно мне пришлось больше узнать о вебе, и я увидел, что URL-адреса более сложные. Например:

  • Drupal ссылки похожи на somewebsite.com/node/43
  • REST-запросы похожи на somewebsite.com/books/32
  • после '?Вы можете передать некоторые параметры

Как это работает? Как работает сервер (или что-то еще? Я довольно новичок) знаете, что означает URL, когда он получает запрос? Возможно:

  • расположение ресурса
  • взгляд друпала
  • Запрос REST
  • другие вещи?

Я не знаю, имеет ли мой вопрос смысл, надеюсь, вы понимаете, в чем суть моего замешательства.

2 ответа2

0

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

Если программа не настроена, она ищет файл с таким именем и обслуживает его напрямую. (PHP и CGI часто находится где - то посередине: веб - сервер все еще ищет файл, но затем запускает этот файл самого как программа.)

Таким образом, единственное, что в /node/43 делает его "представлением Drupal", - это веб-сервер, настроенный для передачи /node/<anything> в программное обеспечение Drupal. Веб-страница по-прежнему считается ресурсом, хотя она была сгенерирована динамически.

(Сам Drupal, конечно, знает, что если путь начинается с /node/ ним будет следовать ID представления.)

REST-запросы также являются полностью регулярными запросами ресурсов; что делает их "RESTful" - это просто общий стиль и поведение. (Например, URL в стиле /book/345 соответствуют идеологии REST, тогда как /api/get_book?id=345 нет.)

0

Как это работает?

Сервер решает.

Как работает сервер (или что-то еще? Я довольно новичок) знаете, что означает URL, когда он получает запрос?

Сервер полагается на свою конфигурацию. Для серверов на основе Unix это часто обрабатывается одним или несколькими текстовыми файлами, которые часто называют файлами конфигурации. При настройке сервера вы можете указать это. Подробная информация о том, как это указать, зависит от того, какое программное обеспечение веб-сервера вы используете.

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

Клиент HTTP 1.1 имеет тенденцию разбивать URL на 3 части:

  • Протокол (например, http/https)
  • Сайт (например, example.com)
  • ресурс (например, /somedir/file.htm)

Это может быть небольшим упрощением. Некоторые старые URL-адреса допускают что-то вроде ftp://username @ password:example.com/somedir/file, хотя более новые веб-браузеры, как правило, удаляют такую поддержку, например MS KB 8344389, из соображений безопасности (включая значительное количество злоупотреблений, которые произошло, например, http://paypal.com/gibberish%40PhishingSite.example.com/gibberish конвертирует% 40 в ASCII 64, который является @, в результате чего имя пользователя paypal.com/gibberish будет использоваться для входа в PhishingSite. .example.com, который просто примет логин и попросит людей ввести пароль PayPal. Люди будут видеть paypal.com в начале URL и доверять ему.

Конечно, есть некоторые "стандарты", такие как # в URL - это то, что веб-клиент распознает и не отправит на сервер. Вместо этого веб-клиент будет обрабатывать текст после # как текст привязки для перехода. Кроме того,% используется для экранирования шестнадцатеричных символов. Веб-клиенты, как правило, понимают это.

Другие детали могут зависеть от сервера. Например, у многих веб-серверов есть? запуск списка параметров и использование & (или много точек с запятой?) для разделения параметров в списке параметров. Тем не менее, это обычное поведение многих веб-серверов. Нет части HTTP, которая заставляет веб-серверы соблюдать это. Действительно, веб-сервер может справиться с этим так, как хочет веб-сервер, и веб-клиенту вряд ли потребуется какая-либо специальная поддержка для этого.

Если вы когда-нибудь настроите HTTP-сервер, вы, вероятно, поймете, что часть этой конфигурации указывает, что делать с запрошенными ресурсами. Например, вы можете сказать, что все, что отправлено в / будет загружать файлы с локального жесткого диска / srv / httpdocs / area, за исключением / cgi-bin /, который будет запускать программу, расположенную в / cgi-bin /, и все, что в / scripts / и заканчивающийся на .pl будет выполняться интерпретатором PERL.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .