Що означає подвійний нахил в URL-адресах?

Що саме означає подвійні риски, які часто зустрічаються в URL-адресі?

Наприклад:

• http://www.example.com/A/B//C/

Зверніть увагу, що я не маю на увазі початку відразу після http:.

Це помилка в коді програмістів / розробників. Якщо порівняти ці дві URL-адреси:

• http://www.example.com/A/B/C/
• http://www.example.com/A/B//C/

Вони виглядають інакше, але якби ви відвідували будь-який, обидва вони працювали б у більшості сучасних браузерів.

Це те, що ви хочете виправити. Якщо ви маєте подвійну косу рису, це може заплутати веб-сканери Google і змусити їх думати, що існує 2 версії сторінки.

Як згадував @RandomBen , подвійна косою рисою скоріш за все є результатом десь помилки.

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

GET /A/B//C/D HTTP/1.1
Host: www.example.com
...

Схоже, що поточні версії Apache та IIS обидва будуть ігнорувати зайві косої риски під час вирішення шляху та повертати документ, який був би повернутий, якби URL-адреса не мала зайвих косої риски. Однак браузери (я тестував IE 8 та Chrome 9) заплутуються будь-якими відносними URL-адресами (що містять батьківські шляхи) ресурсів сторінки, що дає погані результати. Наприклад, якщо на сторінці є:

<link rel="stylesheet" href="../../style.css" type="text/css" />

Після завантаження сторінки /a/b/c/браузер подасть запит /a/style.css. Але якщо з будь-якої причини /a/b//c/буде запропоновано запит (а сервер ігнорує додаткову косу рису), браузер в кінцевому підсумку подасть запит /a/b/style.css, який не буде існувати. На жаль, сторінка виглядає некрасиво.

(Це, очевидно, не відбудеться, якщо в URL-адресі немає компонента батьківського шляху ( ..) або абсолютна.)

Це моя думка , що Apache і IIS (і , можливо , інші) діють неправильно , як /a/b/c/і /a/b//c/технічно представляють собою два різних ресурсів. Згідно з RFC 2396 , кожна коса риса є значною:

  path          = [ abs_path | opaque_part ]

  path_segments = segment *( "/" segment )
  segment       = *pchar *( ";" param )
  param         = *pchar

  pchar         = unreserved | escaped |
                  ":" | "@" | "&" | "=" | "+" | "$" | ","

Отже, /a/b/c/складається з трьох сегментів: "a", "b" та "c"; /a/b//c/насправді складається з чотирьох: "a", "b", "" (порожній рядок) та "c". Незалежно від того, чи порожній рядок є дійсною каталогом файлової системи, це деталь платформи сервера. (І, логічно, це означає, що браузери насправді працюють правильно, коли аналізують відносні URL-адреси з компонентами батьківського контуру - у моєму прикладі вони проходять повз каталог "c" та каталог "", залишаючи нам запит style.cssвід "b".)

Якщо ви використовуєте Apache з mod_rewrite, є досить просте виправлення :

# remove multiple slashes anywhere in url 
RewriteCond %{REQUEST_URI} ^(.*)//(.*)$ 
RewriteRule . %1/%2 [R=301,L] 

Це призведе до 301 Moved Permanentlyперенаправлення HTTP, так що будь-які подвійні косої риски будуть позбавлені URL-адреси.

Подвійний нахил має значення, коли він використовується в URL-адресах ресурсу. Наприклад, коли це користувач у CSS для URL фонового зображення:

.classname {
    background : url("//example.com/a/b/c/d.png");
}

Тут це означає, що це фонове зображення отримує з іншого домену, крім домену цієї веб-сторінки. Або іншими словами, http://може бути записаний так само, //коли використовується в URL-адресі ресурсу.

Але цей подвійний проріз між URL-адресами (наприклад /a//b/c/d.htm:) не має жодного значення.

Як уже згадувалося, деякі сервери налаштовані ігнорувати подвійну косу рису в шляху URL, але статичний хостинг Amazon S3 не буде. Якщо ви хочете обробляти / ігнорувати їх у такому випадку, ви можете використовувати правила перенаправлення на панелі властивостей.

Якщо ви хочете ігнорувати подвійну косу рису після доменного імені, ви можете використовувати щось подібне:

<RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyPrefixEquals>/</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <ReplaceKeyPrefixWith/>
    </Redirect>
  </RoutingRule>
</RoutingRules>

Ви, ймовірно, також можете їх знайти та замінити на всьому протязі, але цього мені було достатньо.