У URL-адресі для чого // [зачинено]

39

Як правило, коли я бачу //, це зазвичай після деякого префіксу протоколу, як http:або ftp:. Я ніколи не бачив, щоб його розміщували більше ніде. Наприклад,

http://www.google.com/

- типова URL-адреса.

Однак я знайшов наступні два синтаксиси, щоб отримати різні версії одного і того ж сайту,

http://www.weather.com/

http://www.weather.com//

Я б подумав, що //деінде, окрім специфікації протоколу, буде недійсним. На моє здивування, я помилився. Що з того, що закінчення //випускає іншу версію того ж сайту?

Редагувати:

Хтось із цього сайту, мабуть, спіткнувся з іншого, тому що обидва посилання тепер приземляються на одній сторінці.

url syntax uri

— Чад Гаррісон
джерело

9

Якби я мав здогадуватися, все, що ти робиш, - це бачити один і той же сайт двічі, але той, який має додаткові / в кінці, зламає CSS або те, що діти в ці дні використовують для форматування своїх веб-сайтів. :)

— Марк Аллен

webmasters.stackexchange.com може бути краще підходить для цього питання.

— Мехпер К. Палавузлар

1

@ MehperC.Palavuzlar В ретроспективі, так. Але на момент запитання я вважав, що сфера застосування дещо ширша, ніж є.

— Чад Гаррісон

@MarkAllen Добре цікаво зазначити, що використання ///або ////в кінці URL-адреси призвело до того самого сайту, що і /де, // що призвело до чогось іншого.

— Чад Гаррісон

Тим часом подвійний нахил (\\) зазвичай зустрічається в Єдиній конвенції про іменування Windows, наприклад,\\HostName[@Port]\SharedFolder\Resource

— William C

67

Основна //частина є частиною синтаксису URL. Винахідник всесвітньої павутини вибачився за цю помилку .

Дійсно, якщо ви подумаєте про це, йому не потрібен подвійний косий переріз. Я міг би спроектувати це, щоб не було подвійної косої риски. - Сер Тім Бернерс-Лі, винахідник всесвітньої павутини

Що стосується останнього //, то насправді це не подвійний наріз. Перша коса риса відокремлює ім'я хоста від шляху. Остання риса - шлях. Веб-сервер може, якщо захоче, обробити шлях, /відмінний від порожнього шляху, і, мабуть, робить weather.com. Що стосується того, чи це випадково чи навмисно, вам доведеться запитати їх про це.

— Девід Шварц
джерело

Це стає завершеним, оскільки ви можете налаштувати веб-сервер на пошук індексу, відмінного від веб-кореня! Мій капелюх вам добрий сер.

— Чад Гаррісон

Ви говорите, http://example.comчи можна по-різному ставитися до http://example.com/? Я не думав, що так було з першою косою рисою.

— НезадоволенеГота

1

@DisgruntledGoat Ви можете , так, використовуючи деякі .htaccessправила. Але ти, мабуть, не повинен.

— Матвій

1

Ви не можете ставитися до веб-сервера, який http://example.comвідрізняється http://example.com/, оскільки вони мають порожній шлях. Ви можете по-різному ставитися до них у веб-переглядачі.

— Девід Шварц

3

ніколи неGET / HTTP/1.1

— замислюючи

19

Зовсім недавно, можна стверджувати , що подвійний слеш робить свою роль. Рекомендуємо Google (щоб уникнути випадкового виклику незахищеного вмісту із захищеної сторінки, наприклад) пропустити протокол із вбудованих ресурсів (таблиці стилів, js тощо), як це

<script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>

Тож очевидно, що така URL-адреса, яка не містить протоколу, - це повністю кваліфікована URL-адреса, а не відносна URL-адреса (яка починалася б з однієї косої риски).

— DaveP
джерело

1

Цей стиль називається URL-адресою / URI "відносно протоколу". Є подібні запитання щодо SO.

— hippietrail

1

Більше не рекомендую. Дивіться також paulirish.com/2010/the-protocol-relative-url

— lorond

13

Насправді відповідь на питання, оригінальний специфікація дав протокол http:(або , можливо ftp:, gopher:, mailto:, news:, telnet:, wais:, file:або prospero:) , то , // щоб вказати , що Uniform Resource Locator (URL) синтаксис використовувався, то господар (можливо з префіксом user:password@) , то адреса належне починаючи з іншого /. Це було запропоновано в RFC 1738 .

По мірі того, як Інтернет розвивався, http:став домінуючим протоколом, і тепер браузери припускають, що префікс http://має бути доданий, якщо його немає.

— StarNamer
джерело

3

Здається, ваша відповідь вказує на те, що з протоколом в один момент могло бути використано щось інше, ніж URL, і він би використав щось інше, ніж //вказати, що воно використовується ... Це так?

— Ізката

3

@Izkata Наприкінці 80-х та 90-х, коли Інтернет запускався, було запропоновано кілька різних форматів для різних предметів. URL-адреси були / є підмножиною URN (див. RFC 3305), і вони можуть мати різні формати, наприклад isbn:1-23-456789-12-3. На практиці http:визначає, що решта буде URL-адресою. RFC - це лише пропозиції та часто дозволяють розширення, які ніколи не реалізуються. Одного разу Тім Бернерс-Лі сказав, що //це "підмережа" (напр. http:/govnet/whitehouse.gov). Ця ідея ніколи не використовувалася, але "//" залишається стільки, скільки зараз очікує і перевіряє її.

— StarNamer

1

@Izkata: ви, мабуть, не побачите URN без URL-адреси, який використовується з протоколом зв'язку; ось для чого //. Він вказує, що протокол використовується для доступу до (можливо, віддаленого) мережевого місця, де потрібно знайти ресурс. Там є багатьма інших URN , у яких є інші частини даних і не використовує // (ваш браузер , ймовірно , визнає «електронна пошта:», наприклад). Дивіться: en.wikipedia.org/wiki/URI_scheme

— KutuluMike

@MichaelEdenfield Ну, ось що мені зараз цікаво. Чи коли-небудь був момент, коли це було призначено використовувати по-різному - щось інше, що могло б спілкуватися через один і той же протокол. В якості грубого прикладу, може намір свого часу було для http://www.google.com/і http:%/74.125.225.97/до обох бути дійсними, і //вказати ім'я хоста , а що - то інше , як %/вказати IP - адреса?

— Ізката

1

Я не думаю, що так. Принаймні, я ніколи не бачив жодних проектів документів / прикладів / тощо, які б мали альтернативну схему ієрархії URL-адрес. Моє враження завжди було, що TBL просто хотів щось зробити так, щоб було очевидно, що URL-адреса вказує на фактичний ресурс (а не на довільні дані), і використання // зроблених речей виглядає достатньо файлоподібним. У кожному іншому стилі URN, який я коли-небудь бачив, немає спеціальної префікса у своїй частині даних. Деякі протоколи це дозволяють (я думаю, telnet і gopher, наприклад), але я ніколи не бачив нічого подібного для http (s).

— KutuluMike

1

Я хотів би додати прийняту відповідь Девіда:

Незважаючи на вибачення винахідника Інтернету, я думаю, що синтаксис з подвійною косою рисою слугував важливою метою: візуально виділитися. Подвійні риски дозволяють легко візуально розрізняти URL-адреси в тексті без гіперпосилань. Побачивши подвійну косу рису, ви відразу подумали, що її можна ввести у вікно браузера, подібно до того, як ви думали, що містить текст@може бути використаний для надсилання електронного листа. Це було особливо важливо під час фази переходу до Інтернету, де протоколи тієї епохи (ftp, telnet, gopher) мали своє дивне уявлення про представлення адрес сервера або шляхів до ресурсів, рідко обох. Більшість проблем, пов’язаних із подвійними косою рисою, все одно існуватимуть, оскільки подвійні косої риски є найменш криптичною частиною URL-адреси, подумайте про кількість портів, відсотковий кодування та чутливість до регістру. Але мати таку URL-адресу, як http: something.com можна легко сплутати з моїм прикладом тут: something.com. Подивіться на http: // з іншого боку, як він світить, як алмаз. Подвійні косої риски були важливою частиною веб-символіки, і я вважаю, що це також прискорило її прийняття, навіть якщо це було ненавмисно.

Вони також могли б полегшити роботу AmigaOS для розмежування імен файлів та URL-адрес, оскільки AmigaOS використовував синтаксис шляху до файлу volume:path/to/destination. :)

— Седат Капаноглу
джерело