Odpowiedzi:
Zasadniczo za najlepszą praktykę uważa się stosowanie względnych adresów URL, aby Twoja witryna nie była powiązana z podstawowym adresem URL miejsca, w którym jest obecnie wdrażana. Na przykład będzie mógł pracować na localhost, a także na domenie publicznej, bez modyfikacji.
Jeśli przez bezwzględne adresy URL masz na myśli adresy URL, w tym schemat (np. Http / https) i nazwę hosta (np. Twojadomena.com), nigdy tego nie rób (w przypadku zasobów lokalnych), ponieważ utrzymanie i debugowanie będzie trudne.
Załóżmy, że użyłeś bezwzględnego adresu URL wszędzie w kodzie, np <img src="http://yourdomain.com/images/example.png">. Co się stanie, kiedy będziesz:
W pierwszym przykładzie pojawi się ostrzeżenie o żądaniu niebezpiecznych treści na stronie. Ponieważ wszystkie adresy URL są zakodowane na stałe, aby używać http (: //twojadomena.com/images/example.png). Podczas uruchamiania stron przez https przeglądarka oczekuje, że wszystkie zasoby zostaną załadowane przez https, aby zapobiec wyciekom informacji.
W drugim przykładzie umieszczenie witryny na żywo ze środowiska testowego oznaczałoby, że wszystkie zasoby nadal wskazują domenę testową zamiast domeny aktywnej.
Aby odpowiedzieć na pytanie, czy używać bezwzględnych czy względnych adresów URL: zawsze używaj względnych adresów URL (dla zasobów lokalnych).
Najpierw spójrzmy na różne typy adresów URL, których możemy użyć:
http://yourdomain.com/images/example.png//yourdomain.com/images/example.png/images/example.pngimages/example.pngW poniższych przykładach zakładam, że witryna działa z następującej lokalizacji na serwerze /var/www/mywebsite.
http://yourdomain.com/images/example.png
Powyższy (bezwzględny) adres URL próbuje uzyskać dostęp do zasobu /var/www/website/images/example.png. Ten typ adresu URL jest czymś, czego zawsze chciałbyś unikać, prosząc o zasoby z własnej witryny z powodów opisanych powyżej. Ma jednak swoje miejsce. Na przykład, jeśli masz witrynę internetową http://yourdomain.comi chcesz poprosić o zasób z domeny zewnętrznej za pośrednictwem protokołu https, powinieneś go użyć. Np https://externalsite.com/path/to/image.png.
//yourdomain.com/images/example.png
Ten adres URL jest względny w oparciu o aktualny zastosowany schemat i prawie zawsze powinien być używany, gdy zawiera zasoby zewnętrzne (obrazy, skrypty javascript itp.).
Ten typ adresu URL korzysta z bieżącego schematu strony, na której się znajduje. Oznacza to, że jesteś na stronie, http://yourdomain.coma na tej stronie znajduje się tag obrazu, <img src="//yourdomain.com/images/example.png">w którym adres URL obrazu zostałby rozpoznany http://yourdomain.com/images/example.png.
Gdybyś był na stronie, http**s**://yourdomain.coma na tej stronie znajduje się tag obrazu, <img src="//yourdomain.com/images/example.png">adres URL obrazu zostanie rozpoznany https://yourdomain.com/images/example.png.
Zapobiega to ładowaniu zasobów przez https, gdy nie jest to potrzebne, i automatycznie upewnia się, że zasób jest wymagany przez https, gdy jest potrzebny.
Powyższy adres URL rozwiązuje się w ten sam sposób po stronie serwera, co poprzedni adres URL:
Powyższy (bezwzględny) adres URL próbuje uzyskać dostęp do zasobu
/var/www/website/images/example.png.
/images/example.png
W przypadku zasobów lokalnych jest to preferowany sposób odwoływania się do nich. To względny adres URL oparty na katalogu głównym dokumentu ( /var/www/mywebsite) witryny. Oznacza to, że kiedy już <img src="/images/example.png">to zrobisz, zawsze to rozwiąże /var/www/mywebsite/images/example.png.
Jeśli w pewnym momencie zdecydujesz się na zmianę domeny, nadal będzie działać, ponieważ jest względna.
images/example.png
Jest to również względny adres URL, choć nieco inny niż poprzedni. Ten adres URL jest względny do bieżącej ścieżki. Oznacza to, że rozwinie się na różne ścieżki w zależności od tego, gdzie jesteś na stronie.
Na przykład, gdy jesteś na stronie http://yourdomain.comi używasz <img src="images/example.png">go, rozwiąże się on na serwerze /var/www/mywebsite/images/example.pngzgodnie z oczekiwaniami, jednak gdy jesteś na stronie http://yourdomain.com/some/pathi użyjesz dokładnie tego samego tagu graficznego, to nagle zostanie rozwiązany /var/www/mywebsite/some/path/images/example.png.
Żądając zasobów zewnętrznych, najprawdopodobniej chcesz użyć adresu URL względem schematu (chyba że chcesz wymusić inny schemat), a podczas korzystania z zasobów lokalnych, chcesz użyć względnych adresów URL opartych na katalogu głównym dokumentu.
Przykładowy dokument:
<!DOCTYPE html>
<html>
<head>
<title>Example</title>
<link href='//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700' rel='stylesheet' type='text/css'>
<link href="/style/style.css" rel="stylesheet" type="text/css" media="screen"></style>
</head>
<body>
<img src="/images/some/localimage.png" alt="">
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script>
</body>
</html>Zobacz: http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
foo://username:password@example.com:8042/over/there/index.dtb;type=animal?name=ferret#nose
\ / \________________/\_________/ \__/ \___/ \_/ \_________/ \_________/ \__/
| | | | | | | | |
| userinfo hostname port | | parameter query fragment
| \_______________________________/ \_____________|____|____________/
scheme | | | |
| authority |path|
| | |
| path interpretable as filename
| ___________|____________ |
/ \ / \ |
urn:example:animal:ferret:nose interpretable as extensionBezwzględny adres URL zawiera części poprzedzające część „ścieżki” - innymi słowy, zawiera schemat ( httpin http://foo/bar/baz) i nazwę hosta ( fooin http://foo/bar/baz) (i opcjonalnie port, informacje o użytkowniku i port).
Względne adresy URL zaczynają się od ścieżki.
Bezwzględne adresy URL są, no cóż, absolutne: lokalizację zasobu można rozwiązać, patrząc tylko na sam adres URL. Względny adres URL jest w pewnym sensie niekompletny: aby go rozwiązać, potrzebujesz schematu i nazwy hosta, które zazwyczaj są pobierane z bieżącego kontekstu. Na przykład na stronie internetowej pod adresem
http://myhost/mypath/myresource1.htmlmożesz umieścić taki link
<a href="pages/page1">click me</a>W hrefatrybucie linku użyto względnego adresu URL, a jeśli zostanie kliknięty, należy go rozwiązać, aby go śledzić. W tym przypadku bieżącym kontekstem jest
http://myhost/mypath/myresource1.htmlwięc schemat, nazwa hosta i ścieżka wiodąca są pobierane i dołączane do nich pages/page1, dając wynik
http://myhost/mypath/pages/page1Gdyby link był:
<a href="/pages/page1">click me</a>(zwróć uwagę na /pojawienie się na początku adresu URL), wówczas zostałby rozwiązany jako
http://myhost/pages/page1ponieważ interlinia /wskazuje katalog główny hosta.
W aplikacji internetowej radzę używać względnych adresów URL dla wszystkich zasobów należących do Twojej aplikacji. W ten sposób, jeśli zmienisz lokalizację stron, wszystko będzie nadal działać. Wszelkie zasoby zewnętrzne (mogą to być strony całkowicie poza twoją aplikacją, ale także treść statyczna dostarczana przez sieć dostarczania treści) powinny zawsze być wskazywane za pomocą bezwzględnych adresów URL: jeśli nie, po prostu nie ma możliwości ich zlokalizowania, ponieważ one rezydują na innym serwerze.
//example.com/…, ?foobara #foobartakże są względnymi adresami URL i nie zaczynają się od ścieżki adresu URL (no dobrze, bo ?foobarmożna powiedzieć, że zaczyna się od pustej ścieżki).
//example.com/…adresy URL typu są nazywane względnymi? to dla mnie nowe.
Załóżmy, że tworzymy podwitrynę, której pliki znajdują się w folderze http://site.ru/shop .
Link to home page
href="http://sites.ru/shop/"
Link to the product page
href="http://sites.ru/shop/t-shirts/t-shirt-life-is-good/"Link from home page to product page
href="t-shirts/t-shirt-life-is-good/"
Link from product page to home page
href="../../"Chociaż względny adres URL wygląda na krótszy niż bezwzględny, ale bezwzględne adresy URL są bardziej preferowane, ponieważ łącza można używać w niezmienionej formie na dowolnej stronie witryny.
Rozważaliśmy dwa skrajne przypadki: „absolutnie” absolutne i „absolutnie” względne adresy URL. Ale na tym świecie wszystko jest względne. Dotyczy to również adresów URL. Za każdym razem, gdy mówisz o bezwzględnym adresie URL, zawsze powinieneś określać w stosunku do czego.
Link to home page
href="//sites.ru/shop/"
Link to product page
href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"Google zaleca taki adres URL. Teraz jednak powszechnie uważa się, że http: // i https: // to różne witryny.
Tj. W stosunku do folderu głównego domeny.
Link to home page
href="/shop/"
Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"To dobry wybór, jeśli wszystkie strony znajdują się w tej samej domenie. Po przeniesieniu witryny do innej domeny nie musisz masowo zastępować nazwy domeny w adresach URL.
Tag <base> określa podstawowy adres URL, który jest automatycznie dodawany do wszystkich względnych łączy i kotwic. Tag podstawowy nie wpływa na linki bezwzględne. Jako podstawowy adres URL podamy stronę główną: <base href = "http://sites.ru/shop/">.
Link to home page
href=""
Link to product page
href="t-shirts/t-shirt-life-is-good/"Teraz możesz przenieść swoją witrynę nie tylko do dowolnej domeny, ale w dowolnym podfolderze. Pamiętaj tylko, że chociaż adresy URL wyglądają względnie, w rzeczywistości są absolutne. Zwróć szczególną uwagę na kotwice. Aby poruszać się po bieżącej stronie, musimy napisać href = "t-shirty / t-shirt-life-is-good / # comments" not href = "# comments". Ten ostatni wrzuci na stronę główną.
W przypadku linków wewnętrznych używam adresów URL względnych względem bazy (5). W przypadku zewnętrznych linków i biuletynów używam bezwzględnych adresów URL (1).
Istnieją naprawdę trzy typy, które powinny zostać wyraźnie omówione. W praktyce jednak adresy URL zostały wyodrębnione, aby mogły być obsługiwane na niższym poziomie, i posunąłbym się nawet do stwierdzenia, że programiści mogą przejść przez całe życie bez ręcznego pisania pojedynczego adresu URL.
Bezwzględne adresy URL wiążą kod z protokołem i domeną. Można to rozwiązać za pomocą dynamicznych adresów URL.
<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>Absolutni plusy:
Kontrola - poddomeną i protokołem można sterować. Osoby, które wejdą przez niejasną subdomenę, zostaną umieszczone w odpowiedniej subdomenie. W razie potrzeby możesz przeskakiwać między bezpiecznymi i niezabezpieczonymi.
Konfigurowalny - programiści uwielbiają być absolutni. Korzystając z bezwzględnych adresów URL, możesz zaprojektować zgrabne algorytmy. Adresy URL można skonfigurować, aby można było aktualizować adres URL w całej witrynie za pomocą jednej zmiany w jednym pliku konfiguracyjnym.
Jasnowidzenie - możesz wyszukiwać osoby przeglądające witrynę lub znaleźć dodatkowe linki zewnętrzne.
Root Względne adresy URL wiążą kod z podstawowym adresem URL. Można to rozwiązać za pomocą dynamicznych adresów URL i / lub tagów podstawowych .
<a href=“/index.php?q=”>.example.com/index.php?q=</a>Względne zalety root:
Względne adresy URL wiążą kod ze strukturą katalogu. Nie ma sposobu na przezwyciężenie tego. Względne adresy URL są przydatne tylko w systemach plików do przeglądania katalogów lub jako skrót do zadania służącego.
<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />Względne wady:
CONFUSING - ile to kropek? ile to jest folderów? Gdzie jest plik? Dlaczego to nie działa?
KONSERWACJA - Jeśli plik zostanie przypadkowo przeniesiony, zasoby zostaną zakończone ładowaniem, linki odsyłają użytkownika do niewłaściwych stron, dane formularza mogą być wysyłane na niewłaściwą stronę. Jeśli plik POTRZEBUJE zostać przeniesiony, wszystkie zasoby, które mają zostać zakończone ładowanie, i wszystkie łącza, które będą nieprawidłowe, muszą zostać zaktualizowane.
NIE SKALUJE - gdy strony stają się bardziej złożone i widoki zaczynają być ponownie wykorzystywane na wielu stronach, odnośniki względne będą względne w stosunku do pliku, do którego zostały dołączone. Jeśli masz fragment nawigacji HTML, który będzie na każdej stronie, krewny będzie względny w wielu różnych miejscach. Pierwszą rzeczą, którą ludzie zdają sobie sprawę, gdy zaczynają tworzyć szablon, jest to, że potrzebują sposobu na zarządzanie adresami URL.
WYLICZONE - są implementowane przez Twoją przeglądarkę (mam nadzieję, że zgodnie z RFC). Patrz rozdział 5 w RFC3986 .
OOPS! - Błędy lub literówki mogą powodować pułapki na pająki.
Programiści przestali pisać adresy URL w omawianym tutaj znaczeniu. Wszystkie żądania dotyczą pliku indeksu witryny i zawierają ciąg zapytania, czyli trasę. Trasę można traktować jako mini URL, który informuje aplikację o treści, która ma zostać wygenerowana.
<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
http://dev.example.com/index.php/my:whacky:url
</a>Trasy Plusy:
Większość ludzi w jakiś sposób wykorzysta wszystkie trzy formy w swoich projektach. Kluczem jest ich zrozumienie i wybranie tego, który najlepiej pasuje do zadania.
Jeśli jest przeznaczony do użytku w witrynie, lepiej jest użyć względnego adresu URL, np. Jeśli chcesz przenieść witrynę do innej nazwy domeny lub po prostu debugować lokalnie, możesz.
Zobacz, co robi przepływ stosu (ctrl + U w Firefoksie):
<a href="/users/recent/90691"> // Link to an internal elementW niektórych przypadkach używają bezwzględnych adresów URL:
<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">... ale to tylko najlepsza praktyka, aby poprawić prędkość. W twoim przypadku nie wygląda na to, że robisz coś takiego, więc nie martwiłbym się tym.
Będę musiał się nie zgodzić z większością tutaj.
Myślę, że względny schemat adresów URL jest „w porządku”, gdy chcesz szybko coś uruchomić i nie myśleć nieszablonowo, szczególnie jeśli twój projekt jest niewielki i ma niewielką liczbę programistów (lub tylko ciebie).
Jednak gdy zaczniesz pracować nad dużymi, tłustymi systemami, w których cały czas zmieniasz domeny i protokoły, uważam, że bardziej eleganckie podejście jest w porządku.
Gdy porównujesz w zasadzie bezwzględne i względne adresy URL, Absolute wygrywa. Czemu? Ponieważ nigdy się nie złamie. Zawsze. Bezwzględny adres URL jest dokładnie taki, jak mówi. Chwytem jest, gdy musisz UTRZYMAĆ swoje bezwzględne adresy URL.
Słabe podejście do bezwzględnego linkowania URL-a polega na sztywnym kodowaniu całego adresu URL. Nie jest to świetny pomysł i prawdopodobnie sprawca, dla którego ludzie uważają je za niebezpieczne / złe / irytujące w utrzymaniu. Lepszym rozwiązaniem jest napisanie sobie łatwego w użyciu generatora adresów URL. Są łatwe do napisania i mogą być niewiarygodnie potężne - automatycznie wykrywają protokół, są łatwe do skonfigurowania (dosłownie ustaw adres URL całej aplikacji) itp. I same wstrzykują domenę. Zaletą tego jest to, że nadal kodujesz przy użyciu względnych adresów URL, a w czasie wykonywania aplikacja wstawia adresy URL jako pełne absoluty w locie. Niesamowite.
Ponieważ praktycznie wszystkie nowoczesne witryny korzystają z pewnego rodzaju dynamicznego zaplecza, jest to w najlepszym interesie tej witryny. Bezwzględne adresy URL to coś więcej niż tylko pewność, do kogo wskazują - mogą również poprawić wydajność SEO.
Mogę dodać, że argument, że bezwzględne adresy URL w jakiś sposób zmienią czas ładowania strony, jest mitem. Jeśli Twoja domena waży więcej niż kilka bajtów, a korzystasz z modemu telefonicznego w latach 80., to na pewno. Ale tak już nie jest. https://stackoverflow.com/ ma 25 bajtów, podczas gdy plik „topbar-sprite.png”, którego używają dla obszaru nawigacji witryny, waży 9+ kb. Oznacza to, że dodatkowe dane adresu URL stanowią .2% załadowanych danych w porównaniu do pliku sprite, a ten plik nie jest nawet uważany za duży spadek wydajności.
Ten duży, niezoptymalizowany obraz tła na całej stronie znacznie bardziej spowalnia czas ładowania.
Interesujący post na temat tego, dlaczego nie należy używać względnych adresów URL, znajduje się tutaj: http://yoast.com/relative-urls-issues/
Problem, który może pojawić się na przykład w przypadku krewnych, polega na tym, że mapowania serwerów (pamiętaj o dużych, pomieszanych projektach) nie pokrywają się z nazwami plików, a programista może przyjąć założenie dotyczące względnego adresu URL, który po prostu nie jest prawdziwe. Właśnie to widziałem dzisiaj w projekcie, nad którym pracuję, i sprowadził całą stronę na dół.
A może programista zapomniał zmienić wskaźnik i nagle Google zaindeksował całe środowisko testowe. Ups - zduplikowane treści (złe dla SEO!).
Absoluty mogą być niebezpieczne, ale przy prawidłowym użyciu i w sposób, który nie może zniszczyć twojej wersji , udowodniono, że są bardziej niezawodne. Spójrz na powyższy artykuł, który podaje kilka powodów, dla których generator adresów URL Wordpress jest super niesamowity.
:)
/linku do ścieżki podstawowej? tj. /products/wallets/thing.htmlw przeciwieństwie do thing.htmlw przeciwieństwie dohttp://www.myshop.com/products/wallets/thing.html
echo Route::url('route_name')do zbudowania bezwzględnego adresu URL za pomocą adresu URL witryny i informacji o trasie z opcją wykonania go przez HTTPS.
W większości przypadków względne adresy URL są dobrym rozwiązaniem, są one z natury przenośne, co oznacza, że jeśli chcesz podnieść swoją witrynę i umieścić ją w innym miejscu, natychmiast zadziała, co skróci potencjalnie wiele godzin debugowania.
Jest całkiem przyzwoity artykuł na temat bezwzględnych i względnych adresów URL , sprawdź to.
Adres URL, który zaczyna się od części schematu URL i schemat konkretnego ( http://, https://, ftp://, etc.) jest bezwzględnym URL.
Każdy inny adres URL jest względnym adresem URL i wymaga podstawowego adresu URL, z którego względny adres URL jest rozpoznawany (a zatem zależny od), czyli adresu URL zasobu, w którym używane jest odwołanie, jeśli nie podano inaczej.
Spójrz na RFC 2396 - załącznik C, aby znaleźć przykłady rozwiązywania względnych adresów URL.
Załóżmy, że masz witrynę www.yourserver.com. W katalogu głównym dokumentów internetowych znajduje się podrzędny obraz, aw nim plik myimage.jpg.
Bezwzględny adres URL określa dokładną lokalizację dokumentu, na przykład:
http://www.yourserver.com/images/myimage.jpgWzględny adres URL określa lokalizację względem bieżącego katalogu , na przykład pod warunkiem, że znajdujesz się w głównym katalogu internetowym, w którym znajduje się Twój obraz:
images/myimage.jpg(w stosunku do tego katalogu głównego)
Zawsze należy używać względnych adresów URL tam, gdzie to możliwe. Jeśli przeniesiesz witrynę na www.anotherserver.com, będziesz musiał zaktualizować wszystkie bezwzględne adresy URL wskazujące na www.yourserver.com, względne adresy będą nadal działać bez zmian.
Dla każdego systemu, który obsługuje względną rozdzielczość URI, zarówno względne, jak i bezwzględne URI służą temu samemu celowi: odwoływaniu. I mogą być używane zamiennie. W każdym przypadku możesz zdecydować inaczej. Technicznie zapewniają te same odniesienia.
Mówiąc ściślej, z każdym względnym URI istnieje już bezwzględny URI. I to jest podstawowy identyfikator URI, z którym rozwiązany jest względny identyfikator URI. Względny identyfikator URI jest tak naprawdę funkcją nad bezwzględnymi identyfikatorami URI.
I dlatego też w przypadku względnych identyfikatorów URI możesz zrobić więcej niż w przypadku bezwzględnego identyfikatora URI - jest to szczególnie ważne w przypadku statycznych stron internetowych, które w innym przypadku nie byłyby tak elastyczne w utrzymaniu w porównaniu z bezwzględnymi identyfikatorami URI.
Te pozytywne skutki względnej rozdzielczości URI można również wykorzystać do dynamicznego tworzenia aplikacji internetowych. Wprowadzanie bezwzględnych identyfikatorów URI nieelastyczności jest łatwiejsze do radzenia sobie w środowisku dynamicznym, więc niektórzy programiści, którzy nie są pewni rozdzielczości URI oraz tego, jak prawidłowo ją wdrożyć i zarządzać (nie zawsze jest to łatwe), często decydują się na użycie bezwzględnego Identyfikatory URI w dynamicznej części witryny, ponieważ mogą wprowadzać inne dynamiczne funkcje (np. Zmienną konfiguracyjną zawierającą przedrostek URI), aby obejść brak elastyczności.
Jaka jest zatem korzyść z używania bezwzględnych identyfikatorów URI? Technicznie nie ma, ale powiedziałbym: Względne identyfikatory URI są bardziej złożone, ponieważ należy je rozwiązać w odniesieniu do tak zwanego bezwzględnego podstawowego identyfikatora URI. Nawet rozdzielczość jest ściśle określona od lat, możesz natknąć się na klienta, który ma błąd w rozdzielczości URI. Ponieważ bezwzględne identyfikatory URI nie wymagają rozpoznawania, używanie bezwzględnych identyfikatorów URI nie wiąże się z ryzykiem, że wystąpi wadliwe zachowanie klienta przy względnej rozdzielczości identyfikatora URI. Jak wysokie jest to ryzyko? Cóż, to bardzo rzadkie. Wiem tylko o jednej przeglądarce internetowej, która miała problem z względną rozdzielczością URI. I to nie było ogólnie, ale tylko w bardzo (niejasnym) przypadku.
Obok klienta HTTP (przeglądarki) może być również bardziej skomplikowany dla autora dokumentów hipertekstowych lub kodu. W tym przypadku bezwzględny identyfikator URI ma tę zaletę, że łatwiej go przetestować, ponieważ można go po prostu wprowadzić bez zmian w pasku adresu przeglądarki. Jeśli jednak nie jest to tylko twoja godzinna praca, zazwyczaj lepiej jest zrozumieć bezwzględną i względną obsługę identyfikatora URI, abyś mógł w pełni wykorzystać zalety względnego łączenia.