{"id":89253,"date":"2020-07-21T01:42:24","date_gmt":"2020-07-20T23:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya"},"modified":"2020-07-21T01:42:24","modified_gmt":"2020-07-20T23:42:24","slug":"krutye-uri-ne-izmenyayutsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya","title":{"rendered":"URI cool non vengono modificati","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Autore: Sir Tim Berners-Lee, inventore di URI, URL, HTTP, HTML e del World Wide Web, attuale presidente del W3C. Articolo scritto nel 1998 <\/p>\n

Quale URI pu\u00f2 essere considerato \"cool\"?
\nQuello che non cambia.
\nCome cambiano gli URI?
\nGli URI non cambiano: li cambiano gli esseri umani.<\/i> <\/p>\n

In teoria, non ci sono motivi per cui le persone dovrebbero cambiare gli URI (o smettere di mantenere i documenti), ma nella pratica ce ne sono milioni.<\/p>\n

Teoricamente, il proprietario nominale dello spazio dei nomi di dominio possiede effettivamente lo spazio dei nomi di dominio e, quindi, tutti gli URI in esso. A meno che non si trovi in difficolt\u00e0 finanziarie, nulla impedisce al proprietario del dominio di mantenere quel nome. E teoricamente, lo spazio URI sotto il tuo dominio \u00e8 completamente sotto il tuo controllo, quindi puoi renderlo stabile quanto vuoi. Fondamentalmente, l'unica ragione valida per cui un documento scompare da Internet \u00e8 che l'azienda proprietaria del dominio \u00e8 andata fuori mercato o non pu\u00f2 pi\u00f9 permettersi di mantenere il server. Allora, perch\u00e9 ci sono cos\u00ec tanti link rotti nel mondo? In parte \u00e8 semplicemente una mancanza di previsione. Ecco alcune ragioni che si possono sentire:
\n<\/a><\/noindex><\/p>\n

Abbiamo semplicemente riorganizzato il sito per renderlo migliore.<\/h4>\n

\nDavvero pensi che i vecchi URI non possano pi\u00f9 funzionare? Se \u00e8 cos\u00ec, li hai scelti molto male. Pensa a far s\u00ec che i nuovi resistano anche dopo il prossimo restyling.<\/p>\n

Abbiamo cos\u00ec tanto materiale che non riusciamo a tenere il passo con ci\u00f2 che \u00e8 obsoleto, ci\u00f2 che \u00e8 riservato e ci\u00f2 che \u00e8 ancora pertinente, e quindi abbiamo pensato che fosse meglio semplicemente disattivare tutto.<\/h4>\n

\nPosso solo sympathizzare. Il W3C ha attraversato un periodo in cui dovevamo setacciare attentamente i materiali archiviati per questioni di privacy prima di renderli pubblici. La decisione deve essere ben pensata in anticipo: assicurati di segnalare con ogni documento un pubblico accettabile, la data di creazione e, idealmente, una scadenza. Conserva questi metadati.<\/p>\n

Beh, abbiamo scoperto che \u00e8 necessario spostare i file\u2026<\/h4>\n

\nQuesta \u00e8 una delle scuse pi\u00f9 miserevoli. Molti non sanno che i server web ti consentono di gestire il collegamento tra l'URI di un oggetto e la sua reale ubicazione nel filesystem. Immagina lo spazio URI come uno spazio astratto, perfettamente organizzato. Poi fai una mappatura su qualsiasi realt\u00e0 che stai effettivamente utilizzando per implementarla. Infine, comunica questo al server web. Puoi persino scrivere un frammento del tuo server per farlo correttamente.<\/p>\n

John non supporta pi\u00f9 questo file, ora lo fa Jane.<\/p>\n

Il nome di John era nell'URI? No, semplicemente il file si trovava nella sua directory? Capisco.<\/p>\n

In passato usavamo uno script CGI per farlo, ora usiamo un programma binario.<\/h4>\n

\nC'\u00e8 un'idea folle che le pagine create da script debbano essere collocate nell'area \"cgibin\" o \"cgi\". Questo rivela il meccanismo di come si esegue il proprio server web. Cambi il meccanismo (anche mantenendo il contenuto), e ops \u2014 tutte le tue URI cambiano.<\/p>\n

Prendiamo ad esempio il National Science Foundation (NSF):<\/p>\n

Documenti online NSF<\/p>\n

http:\/\/www.nsf.gov\/cgi-bin\/pubsys\/browser\/odbrowse.pl<\/pre>\n
\nLa prima pagina per iniziare a visualizzare i documenti chiaramente non rimarr\u00e0 tale dopo alcuni anni. cgi-bin<\/code>, oldbrowse<\/code> e pl<\/code>\u00a0\u2014 tutto ci\u00f2 fornisce frammenti di informazioni su come-stiamo-facendo-questo-ora. Se invece utilizzi una pagina per cercare un documento, ottieni inizialmente un risultato altrettanto scarso:<\/p>\n
Rapporto del gruppo di lavoro sulla crittografia e sulla teoria dei codici<\/p>\n
http:\/\/www.nsf.gov\/cgi-bin\/getpub?nsf9814<\/pre>\n
\nper la pagina indice del documento, anche se il documento html stesso appare molto meglio:<\/p>\n
http:\/\/www.nsf.gov\/pubs\/1998\/nsf9814\/nsf9814.htm<\/pre>\n
\nQui il titolo pubs\/1998 offre a qualsiasi futuro servizio di archiviazione una buona chiave per comprendere che opera il vecchio schema di classificazione dei documenti del 1998. Anche se nel 2098 i numeri dei documenti potrebbero apparire diversi, posso immaginare che questo URI sar\u00e0 ancora valido, e non ostacoler\u00e0 NSF o qualsiasi altra organizzazione che gestir\u00e0 l'archivio.<\/p>\n
Non pensavo che gli URL dovessero essere permanenti\u2014ci sono stati URN.<\/h4>\n
\nProbabilmente \u00e8 uno dei peggiori effetti collaterali della discussione sugli URN. Alcuni pensano che a causa della ricerca su uno spazio dei nomi pi\u00f9 permanente possano trattare con superficialit\u00e0 i link interrotti, poich\u00e9 \"URN sistemer\u00e0 tutto questo\". Se sei una di queste persone, permettimi di deluderti.<\/p>\n
La maggior parte degli schemi URN che ho visto somigliano a un identificatore di autorit\u00e0, seguito da una data e da una stringa a scelta, oppure semplicemente dalla stringa che scegli. \u00c8 molto simile a un URI HTTP. In altre parole, se pensi che la tua organizzazione sar\u00e0 in grado di creare URN durature, dimostralo ora utilizzandole per i tuoi URI HTTP. Non c'\u00e8 nulla di instabile nel tuo URI all'interno dell'HTTP. Solo la tua organizzazione. Crea un database che mappa l'URN del documento con l'attuale nome del file e permetti al server web di usarlo per l'effettivo recupero dei file.<\/p>\n
Se sei arrivato a questo punto, se non hai tempo, denaro e contatti per sviluppare un software, puoi elencare la seguente giustificazione:<\/p>\n
Volevamo farlo, ma non abbiamo gli strumenti necessari.<\/h4>\n
\nE questo \u00e8 comprensibile. Sono completamente d'accordo. Quello che devi fare \u00e8 far s\u00ec che il server web gestisca immediatamente l'URI permanente e restituisca il file, ovunque esso si trovi attualmente nel tuo attuale e caotico sistema di file. Vuoi conservare tutti gli URI in un file come verifica e mantenere costantemente aggiornato il database. Vuoi mantenere le relazioni tra le varie versioni e traduzioni dello stesso documento e conservare un registro indipendente del checksum per proteggerti dalla corruzione del file causata da errori casuali. E i server web non vengono forniti con queste funzionalit\u00e0. Quando vuoi creare un nuovo documento, il tuo editor ti chiede di assegnare un URI.<\/p>\n
Hai bisogno della possibilit\u00e0 di modificare la propriet\u00e0, l'accesso al documento, il livello di sicurezza del livello archivistico e altro ancora nello spazio URI senza cambiare l'URI.<\/p>\n
\u00c8 tutto estremamente negativo. Ma sistemeremo la situazione. In W3C utilizziamo la funzionalit\u00e0 Jigedit (server Jigsaw per la modifica), che tiene traccia delle versioni, e stiamo sperimentando con script per la creazione di documenti. Se stai sviluppando strumenti, server e client, presta attenzione a questo problema!<\/p>\n
Questa giustificazione si applica anche a molte pagine del W3C, inclusa questa: quindi fai ci\u00f2 che dico, non ci\u00f2 che faccio.<\/p>\n
Perch\u00e9 dovrei preoccuparmene?<\/h1>\n
\nQuando cambi il URI sul tuo server, non puoi mai sapere con certezza chi avr\u00e0 collegamenti al vecchio URI. Possono provenire da pagine web comuni. I segnalibri alla tua pagina. Il URI potrebbe essere stato scritto a mano nei margini di una lettera a un amico.<\/p>\n
Quando qualcuno clicca su un link e questo \u00e8 rotto, di solito perde fiducia nel proprietario del server. \u00c8 anche deluso, sia emotivamente che realmente, dalla impossibilit\u00e0 di raggiungere il suo obiettivo.<\/p>\n
Molte persone si lamentano costantemente dei link rotti e spero che il danno sia evidente. Spero che sia evidente anche il danno alla reputazione del manutentore del server dove il documento \u00e8 scomparso.<\/p>\n
Cosa devo fare? Progettare l'URI.<\/h1>\n
\n\u00c8 compito del webmaster creare URI che possano essere utilizzati tra 2 anni, 20 anni, 200 anni. Ci vogliono ponderatezza, organizzazione e determinazione.<\/p>\n
Le URI cambiano se cambia qualche informazione in esse. \u00c8 molto importante come le progetti. (Cosa, progettare un URI? Devo progettare un URI? S\u00ec, dovresti pensarci). Progettare significa principalmente garantire l'assenza di informazioni in un URI.<\/p>\n
La data di creazione del documento \u2014 la data di emissione del URI \u2014 \u00e8 qualcosa che non cambier\u00e0 mai. \u00c8 molto utile per separare le richieste che utilizzano un nuovo sistema da quelle che utilizzano un vecchio sistema. \u00c8 un buon punto di partenza per il URI. Se un documento ha una data, anche se rimarr\u00e0 pertinente in futuro, \u00e8 un buon inizio.<\/p>\n
L'unica eccezione \u00e8 la pagina che \u00e8 intenzionalmente l'ultima versione, per esempio, per tutta l'organizzazione o gran parte di essa.<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/latest\/<\/pre>\n
\nQuesta \u00e8 l'ultima colonna di Money Daily nella rivista Money. La ragione principale per cui questo URI non ha bisogno di una data \u00e8 che non ci sono motivi per preservare un URI che sopravvivr\u00e0 alla rivista. Il concetto di Money Daily scomparir\u00e0 quando scomparir\u00e0 Money. Se vuoi fare riferimento ai contenuti, dovresti farlo separatamente negli archivi:<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/1998\/981212.moneyonline.html<\/pre>\n
\n(Sembra buono. Presuppone che \"money\" significhi la stessa cosa durante tutta l'esistenza di pathfinder.com. C'\u00e8 una duplicazione di \"98\" e un inutile \".html\", ma per il resto sembra una URI forte.<\/p>\n
Cosa lasciare da parte<\/h4>\n
\nTutto! A parte la data di creazione, mettendo qualsiasi informazione in un URI, in un modo o nell'altro, ti stai attirando dei guai.<\/p>\n