Risposte:
In generale, si ritiene che sia consigliabile utilizzare URL relativi, in modo che il sito Web non sia associato all'URL di base del luogo in cui è attualmente distribuito. Ad esempio, sarà in grado di funzionare su localhost, così come sul tuo dominio pubblico, senza modifiche.
Se per URL assoluti intendi URL tra cui schema (ad esempio http / https) e il nome host (ad esempio tuodominio.com) non lo fai mai (per risorse locali) perché sarà terribile da mantenere e eseguire il debug.
Supponiamo che tu abbia usato l'URL assoluto ovunque nel tuo codice come <img src="http://yourdomain.com/images/example.png">. Ora cosa succederà quando hai intenzione di:
Nel primo esempio ciò che accadrà è che riceverai avvisi sulla richiesta di contenuti non sicuri nella pagina. Perché tutti i tuoi URL sono hardcoded per usare http (: //yourdomain.com/images/example.png). E quando si eseguono le pagine su https, il browser si aspetta che tutte le risorse vengano caricate su https per evitare la perdita di informazioni.
Nel secondo esempio, quando il tuo sito viene pubblicato dall'ambiente di test, ciò significa che tutte le risorse puntano ancora al tuo dominio di test anziché al tuo dominio live.
Quindi, per rispondere alla tua domanda sull'utilizzo di URL assoluti o relativi: usa sempre gli URL relativi (per le risorse locali).
Per prima cosa diamo un'occhiata ai diversi tipi di URL che possiamo usare:
http://yourdomain.com/images/example.png//yourdomain.com/images/example.png/images/example.pngimages/example.pngNegli esempi seguenti suppongo che il sito Web sia in esecuzione dalla seguente posizione sul server /var/www/mywebsite .
http://yourdomain.com/images/example.png
L'URL sopra (assoluto) tenta di accedere alla risorsa /var/www/website/images/example.png. Questo tipo di URL è qualcosa che vorresti sempre evitare per richiedere risorse dal tuo sito Web per i motivi sopra indicati. Tuttavia ha il suo posto. Ad esempio, se si dispone di un sito Web http://yourdomain.come si desidera richiedere una risorsa da un dominio esterno su https, è necessario utilizzarlo. Es https://externalsite.com/path/to/image.png.
//yourdomain.com/images/example.png
Questo URL è relativo in base allo schema corrente utilizzato e dovrebbe quasi sempre essere utilizzato quando si includono risorse esterne (immagini, javascript ecc.).
Ciò che questo tipo di URL fa è utilizzare lo schema corrente della pagina in cui si trova. Ciò significa che sei sulla pagina http://yourdomain.come su quella pagina c'è un tag immagine che <img src="//yourdomain.com/images/example.png">l'URL dell'immagine dovrebbe risolvere http://yourdomain.com/images/example.png.
Quando saresti stato sulla pagina http**s**://yourdomain.come su quella pagina c'è un tag immagine<img src="//yourdomain.com/images/example.png"> l'URL dell'immagine verrà risolto https://yourdomain.com/images/example.png.
Ciò impedisce il caricamento di risorse su https quando non è necessario e si assicura automaticamente che la risorsa sia richiesta su https quando è necessaria è necessario.
L'URL precedente si risolve nello stesso modo sul lato server dell'URL precedente:
L'URL sopra (assoluto) tenta di accedere alla risorsa
/var/www/website/images/example.png.
/images/example.png
Per le risorse locali questo è il modo preferito di riferirle. Questo è un URL relativo basato sulla radice del documento ( /var/www/mywebsite) del tuo sito web. Ciò significa che quando <img src="/images/example.png">lo avrai sempre risolto/var/www/mywebsite/images/example.png .
Se a un certo punto decidi di cambiare dominio funzionerà comunque perché è relativo.
images/example.png
Anche questo è un URL relativo, sebbene leggermente diverso dal precedente. Questo URL è relativo al percorso corrente. Ciò significa che si risolverà in percorsi diversi a seconda di dove ti trovi nel sito.
Ad esempio, quando sei sulla pagina http://yourdomain.come lo usi <img src="images/example.png">, si risolve sul server /var/www/mywebsite/images/example.pngcome previsto, tuttavia quando sei sulla paginahttp://yourdomain.com/some/path e si utilizza esattamente lo stesso tag immagine a cui improvvisamente si risolverà /var/www/mywebsite/some/path/images/example.png.
Quando si richiedono risorse esterne è molto probabile che si desideri utilizzare un URL relativo allo schema (a meno che non si desideri forzare uno schema diverso) e quando si ha a che fare con risorse locali si desidera utilizzare gli URL relativi in base alla radice del documento.
Un documento di esempio:
<!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>Vedi questo: 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 extensionUn url assoluto include le parti prima della parte "percorso" - in altre parole, include lo schema ( httpin http://foo/bar/baz) e il nome host ( fooinhttp://foo/bar/baz ) (e facoltativamente porta, userinfo e porta).
Gli URL relativi iniziano con un percorso.
Gli URL assoluti sono, beh, assoluti: la posizione della risorsa può essere risolta osservando solo l'URL stesso. Un url relativo è in un certo senso incompleto: per risolverlo, sono necessari lo schema e il nome host e questi sono in genere presi dal contesto corrente. Ad esempio, in una pagina Web all'indirizzo
http://myhost/mypath/myresource1.htmlpotresti mettere un link in questo modo
<a href="pages/page1">click me</a>Nell'attributo hrefdel collegamento viene utilizzato un URL relativo e, se viene cliccato, deve essere risolto per seguirlo. In questo caso, il contesto attuale è
http://myhost/mypath/myresource1.htmlquindi lo schema, il nome host e il percorso principale di questi sono presi e anteposti pages/page1, cedendo
http://myhost/mypath/pages/page1Se il collegamento sarebbe stato:
<a href="/pages/page1">click me</a>(notare la /comparsa all'inizio dell'URL) quindi sarebbe stato risolto come
http://myhost/pages/page1perché il lead /indica la radice dell'host.
In un'applicazione Web, consiglierei di utilizzare gli URL relativi per tutte le risorse che appartengono alla tua app. In questo modo, se cambi la posizione delle pagine, tutto continuerà a funzionare. Tutte le risorse esterne (potrebbero essere pagine completamente esterne all'applicazione, ma anche contenuti statici forniti tramite una rete di distribuzione dei contenuti) dovrebbero sempre essere indicati utilizzando URL assoluti: se non lo fai, non c'è modo di individuarli, perché risiedere su un altro server.
//example.com/…, ?foobarE #foobarsono anche gli URL relativi e non iniziano con il sentiero URL (bene ok, per ?foobarpoter dire che si avvia con un vuoto percorso).
//example.com/…URL di tipo sono chiamati relativi? questo è nuovo per me.
Supponiamo di creare un sito secondario i cui file si trovano nella cartella 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="../../"Sebbene l'URL relativo appaia più corto di quello assoluto, ma gli URL assoluti sono più preferibili, poiché un collegamento può essere utilizzato invariato su qualsiasi pagina del sito.
Abbiamo considerato due casi estremi: URL "assolutamente" assoluti e "assolutamente" relativi. Ma tutto è relativo in questo mondo. Questo vale anche per gli URL. Ogni volta che dici dell'URL assoluto, dovresti sempre specificare in relazione a cosa.
Link to home page
href="//sites.ru/shop/"
Link to product page
href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"Google consiglia tale URL. Ora, tuttavia, si ritiene generalmente che http: // e https: // siano siti diversi.
Vale a dire rispetto alla cartella principale del dominio.
Link to home page
href="/shop/"
Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"È una buona scelta se tutte le pagine si trovano nello stesso dominio. Quando sposti il tuo sito in un altro dominio, non devi effettuare sostituzioni di massa del nome di dominio negli URL.
Il tag <base> specifica l'URL di base, che viene automaticamente aggiunto a tutti i collegamenti e gli ancoraggi relativi. Il tag di base non influisce sui collegamenti assoluti. Come URL di base specificheremo la home page: <base href = "http://sites.ru/shop/">.
Link to home page
href=""
Link to product page
href="t-shirts/t-shirt-life-is-good/"Ora puoi spostare il tuo sito non solo in qualsiasi dominio, ma in qualsiasi sottocartella. Tieni presente che, sebbene gli URL appaiano relativi, in realtà sono assoluti. Prestare particolare attenzione alle ancore. Per navigare all'interno della pagina corrente dobbiamo scrivere href = "t-shirts / t-shirt-life-is-good / # commenti" non href = "# commenti". Quest'ultimo verrà lanciato nella home page.
Per i collegamenti interni utilizzo URL relativi alla base (5). Per i link esterni e le newsletter uso URL assoluti (1).
Esistono davvero tre tipi che dovrebbero essere discussi esplicitamente. In pratica, sebbene gli URL siano stati astratti per essere gestiti a un livello inferiore e vorrei dire che gli sviluppatori potrebbero passare tutta la loro vita senza scrivere un singolo URL a mano.
Gli URL assoluti associano il codice al protocollo e al dominio. Questo può essere superato con URL dinamici.
<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>Pro assoluti:
Controllo : il sottodominio e il protocollo possono essere controllati. Le persone che entrano attraverso un oscuro sottodominio verranno incanalate nel sottodominio appropriato. È possibile spostarsi avanti e indietro tra sicuro e non sicuro come appropriato.
Configurabile - Gli sviluppatori amano che le cose siano assolute. È possibile progettare algoritmi accurati quando si utilizzano URL assoluti. Gli URL possono essere configurati in modo che un URL possa essere aggiornato a livello di sito con una singola modifica in un singolo file di configurazione.
Chiaroveggenza : puoi cercare le persone che raschiano il tuo sito o magari prendere alcuni link esterni extra.
Gli URL relativi alla radice associano il codice all'URL di base. Questo può essere superato con URL dinamici e / o tag di base .
<a href=“/index.php?q=”>.example.com/index.php?q=</a>Pro relativi alla radice:
Gli URL relativi associano il codice alla struttura della directory. Non c'è modo di superare questo. Gli URL relativi sono utili solo nei file system per attraversare le directory o come scorciatoia per un'attività mentale.
<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />Contro relativi:
CONFUSIONE - Quanti punti sono? quante cartelle è quella? Dov'è il file? Perché non funziona?
MANUTENZIONE - Se un file viene spostato accidentalmente, le risorse escono dal caricamento, i collegamenti inviano l'utente alle pagine sbagliate, i dati del modulo potrebbero essere inviati alla pagina errata. Se un file DEVE essere spostato, tutte le risorse che stanno per terminare il caricamento e tutti i collegamenti che saranno errati devono essere aggiornati.
NON SCALA - Quando le pagine Web diventano più complesse e le viste iniziano a essere riutilizzate su più pagine, i collegamenti relativi saranno relativi al file in cui sono stati inclusi. Se hai uno snippet di navigazione HTML che si troverà su ogni pagina, il relativo sarà relativo a molti luoghi diversi. La prima cosa che le persone realizzano quando iniziano a creare un modello è che hanno bisogno di un modo per gestire gli URL.
INFORMATICA - Sono implementati dal tuo browser (si spera secondo RFC). Vedi capitolo 5 in RFC3986 .
OOPS! - Errori o errori di battitura possono provocare trappole di ragno.
Gli sviluppatori hanno smesso di scrivere gli URL, nel senso discusso qui. Tutte le richieste riguardano un file indice di un sito Web e contengono una stringa di query, nota anche come route. Il percorso può essere pensato come un mini URL che indica all'applicazione il contenuto da generare.
<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
http://dev.example.com/index.php/my:whacky:url
</a>Pro:
La maggior parte delle persone farà uso di tutte e tre le forme nei loro progetti in un modo o nell'altro. La chiave è comprenderli e scegliere quello più adatto per l'attività.
Se è da utilizzare all'interno del tuo sito Web, è consigliabile utilizzare l'URL relativo, in questo modo se è necessario spostare il sito Web su un altro nome di dominio o semplicemente eseguire il debug a livello locale, è possibile.
Dai un'occhiata a cosa sta facendo stackoverflow (ctrl + U in firefox):
<a href="/users/recent/90691"> // Link to an internal elementIn alcuni casi usano url assoluti:
<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">... ma questa è solo una buona pratica per migliorare la velocità. Nel tuo caso, non sembra che tu stia facendo qualcosa del genere, quindi non me ne preoccuperei.
Non dovrò essere d'accordo con la maggioranza qui.
Penso che lo schema relativo dell'URL sia "buono" quando si desidera mettere rapidamente in funzione qualcosa e non pensare fuori dagli schemi, in particolare se il progetto è piccolo con pochi sviluppatori (o solo te stesso).
Tuttavia, una volta che inizi a lavorare su grandi sistemi grassi in cui cambi continuamente domini e protocolli, credo che sia necessario un approccio più elegante.
Quando si confrontano gli URL assoluti e relativi in sostanza, vince Absolute. Perché? Perché non si romperà mai. Mai. Un URL assoluto è esattamente quello che dice che è. Il problema è quando devi MANTENERE i tuoi URL assoluti.
L'approccio debole al collegamento URL assoluto è in realtà la codifica rigida dell'intero URL. Non è una grande idea, e probabilmente il colpevole del perché le persone li vedono come pericolosi / malvagi / fastidiosi da mantenere. Un approccio migliore è quello di scrivere un generatore di URL facile da usare. Sono facili da scrivere e possono essere incredibilmente potenti: rilevano automaticamente il protocollo, sono facili da configurare (letteralmente imposta l'URL una volta per l'intera app), ecc. E inietta il tuo dominio da solo. La cosa bella di questo: continui a scrivere codice usando gli URL relativi e in fase di esecuzione l'applicazione inserisce i tuoi URL come assoluti al volo. Eccezionale.
Visto che praticamente tutti i siti moderni usano una sorta di back-end dinamico, è nel migliore interesse di detto sito farlo in quel modo. Gli URL assoluti fanno molto di più che renderti sicuro di dove puntano, ma possono anche migliorare le prestazioni SEO.
Potrei aggiungere che l'argomento secondo cui gli URL assoluti cambieranno in qualche modo il tempo di caricamento della pagina è un mito. Se il tuo dominio pesa più di pochi byte e sei su un modem dialup negli anni '80, certo. Ma non è più così. https://stackoverflow.com/ è di 25 byte, mentre il file "topbar-sprite.png" che usano per l'area di navigazione del sito pesa oltre 9 KB. Ciò significa che i dati URL aggiuntivi sono lo 0,2% dei dati caricati rispetto al file sprite e che il file non è nemmeno considerato un grande successo in termini di prestazioni.
Quell'immagine di sfondo grande, non ottimizzata, a pagina intera ha molte più probabilità di rallentare i tempi di caricamento.
Un post interessante sul perché gli URL relativi non dovrebbero essere utilizzati è qui: http://yoast.com/relative-urls-issues/
Un problema che può sorgere con i parenti, ad esempio, è che a volte le mappature dei server (attenzione ai grandi progetti incasinati) non si allineano con i nomi dei file e lo sviluppatore può ipotizzare un URL relativo che semplicemente non lo è vero. L'ho visto oggi su un progetto in cui mi trovo e ha portato giù un'intera pagina.
O forse uno sviluppatore ha dimenticato di cambiare un puntatore e all'improvviso google ha indicizzato l'intero ambiente di test. Whoops - contenuti duplicati (male per SEO!).
Gli assoluti possono essere pericolosi, ma se usati correttamente e in un modo che non può interrompere la tua build, si sono dimostrati più affidabili. Guarda l'articolo sopra che fornisce una serie di motivi per cui il generatore di URL di Wordpress è fantastico.
:)
/per collegarti al percorso di base? cioè /products/wallets/thing.htmlal thing.htmlcontrario dihttp://www.myshop.com/products/wallets/thing.html
echo Route::url('route_name')per creare un URL assoluto utilizzando l'URL del sito e le informazioni sul percorso con l'opzione per farlo su HTTPS.
Nella maggior parte dei casi gli URL relativi sono la strada da percorrere, sono portatili per natura, il che significa che se volessi sollevare il tuo sito e metterlo qualcun altro dove avrebbe funzionato all'istante, riducendo eventualmente le ore di debug.
C'è un articolo abbastanza decente sugli URL assoluti e relativi , dai un'occhiata.
Un URL che inizia con la parte schema URL e regime specifico ( http://, https://, ftp://, ecc) è un URL assoluto.
Qualsiasi altro URL è un URL relativo e necessita di un URL di base da cui l'URL relativo viene risolto (e quindi dipende da) che è l'URL della risorsa in cui viene utilizzato il riferimento se non dichiarato diversamente.
Dai un'occhiata a RFC 2396 - Appendice C per esempi sulla risoluzione di URL relativi.
Supponiamo che tu abbia un sito www.yourserver.com. Nella directory principale per i documenti Web è presente una sottodirectory immagini e in questo è myimage.jpg.
Un URL assoluto definisce la posizione esatta del documento, ad esempio:
http://www.yourserver.com/images/myimage.jpgUn URL relativo definisce la posizione relativa alla directory corrente , ad esempio, dato che ti trovi nella directory web principale in cui si trova la tua immagine:
images/myimage.jpg(relativo a quella directory principale)
Dovresti sempre utilizzare gli URL relativi, ove possibile. Se sposti il sito su www.anotherserver.com dovresti aggiornare tutti gli URL assoluti che puntavano su www.yourserver.com, quelli relativi continueranno a funzionare così come sono.
Per ogni sistema che supporta la risoluzione URI relativa, entrambi gli URI relativi e assoluti servono allo stesso obiettivo: riferimento. E possono essere usati in modo intercambiabile. Quindi potresti decidere in ogni caso in modo diverso. Tecnicamente, forniscono lo stesso riferimento.
Per essere precisi, con ogni URI relativo esiste già un URI assoluto. E questo è l'URI di base contro cui viene risolto l'URI relativo. Quindi un URI relativo è in realtà una caratteristica in cima agli URI assoluti.
Ed è anche per questo che con gli URI relativi puoi fare di più come con un URI assoluto da solo - questo è particolarmente importante per i siti Web statici che altrimenti non potrebbero essere così flessibili da mantenere rispetto agli URI assoluti.
Questi effetti positivi della risoluzione relativa dell'URI possono essere sfruttati anche per lo sviluppo dinamico di applicazioni Web. Gli URI assoluti di inflessibilità che introducono sono anche più facili da affrontare, in un ambiente dinamico, quindi per alcuni sviluppatori che non sono sicuri della risoluzione degli URI e di come implementarli e gestirli correttamente (non che sia sempre facile) spesso optano per l'uso di assoluti URI in una parte dinamica di un sito Web in quanto possono introdurre altre funzionalità dinamiche (ad es. Variabile di configurazione contenente il prefisso URI) in modo da aggirare la mancanza di flessibilità.
Allora, qual è il vantaggio nell'utilizzare URI assoluti? Tecnicamente non c'è, ma uno direi: gli URI relativi sono più complessi perché devono essere risolti rispetto al cosiddetto URI di base assoluto. Anche la risoluzione è definita rigorosamente da anni, potresti imbatterti in un client che ha un errore nella risoluzione dell'URI. Poiché gli URI assoluti non richiedono alcuna risoluzione, l'utilizzo di URI assoluti non ha alcun rischio di incorrere in comportamenti errati del client con una risoluzione URI relativa. Quindi, quanto è alto quel rischio in realtà? Bene, è molto raro. Conosco solo un browser Internet che ha avuto un problema con la risoluzione URI relativa. E questo non era generalmente, ma solo in un caso molto (oscuro).
Accanto al client HTTP (browser) è forse più complesso anche per un autore di documenti ipertestuali o codice. Qui l'URI assoluto ha il vantaggio di essere più facile da testare, dato che puoi semplicemente inserirlo così com'è nella barra degli indirizzi del tuo browser. Tuttavia, se non è solo il tuo lavoro di un'ora, è molto più utile per te comprendere effettivamente la gestione URI assoluta e relativa in modo da poter effettivamente sfruttare i vantaggi del collegamento relativo.