{"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 interessanti non cambiano","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Autore \u2014 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: sono le persone che li cambiano.<\/i> <\/p>\n

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

Teoreticamente, il proprietario nominale dello spazio dei nomi di dominio possiede effettivamente lo spazio dei nomi di dominio e, di conseguenza, tutti gli URI in esso. A parte l'insolvenza, nulla impedisce al proprietario del nome di dominio di mantenere quel nome. E teoreticamente, lo spazio URI sotto il tuo nome di dominio \u00e8 completamente sotto il tuo controllo, quindi puoi renderlo stabile quanto desideri. In una certa misura, l'unica ragione valida per cui un documento scompare da Internet \u00e8 che l'azienda che possedeva il nome di dominio ha chiuso o non pu\u00f2 pi\u00f9 permettersi di mantenere il server operativo. Allora perch\u00e9 ci sono cos\u00ec tanti link interrotti 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

\nPensi davvero che i vecchi URI non possano pi\u00f9 funzionare? Se \u00e8 cos\u00ec, li hai scelti molto male. Pensa a fare in modo che i nuovi siano conservati dopo il prossimo redesign.<\/p>\n

Abbiamo cos\u00ec tanto materiale che non possiamo tenere traccia di ci\u00f2 che \u00e8 obsoleto, di ci\u00f2 che \u00e8 riservato e di ci\u00f2 che \u00e8 ancora rilevante, quindi abbiamo pensato che fosse meglio disattivare tutto ci\u00f2.<\/h4>\n

\nPosso solo esprimere la mia solidariet\u00e0. W3C ha attraversato un periodo in cui dovevamo setacciare attentamente i materiali archiviati per motivi di riservatezza prima di renderli pubblici. \u00c8 necessaria una pianificazione anticipata: assicurati di registrare per ogni documento il pubblico accettabile, la data di creazione e, idealmente, la durata. Mantieni questi metadati.<\/p>\n

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

\nQuesta \u00e8 una delle scuse pi\u00f9 tristi. Molti non sanno che i server web ti permettono di gestire la relazione tra l'URI di un oggetto e il suo effettivo posizionamento nel filesystem. Immagina lo spazio URI come uno spazio astratto, perfettamente organizzato. Poi effettua una mappatura nella realt\u00e0 che stai effettivamente utilizzando per la sua implementazione. Infine, comunica tutto questo al server web. Puoi persino scrivere un frammento del tuo server per far funzionare tutto 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? Chiaro.<\/p>\n

Prima usavamo uno script CGI per questo, ora utilizziamo un programma binario.<\/h4>\n

\nC'\u00e8 un'idea folle che le pagine create da script debbano trovarsi nella directory \"cgibin\" o \"cgi\". Questo rivela il funzionamento del modo in cui esegui il tuo server web. Cambi il funzionamento (anche mantenendo il contenuto) e, ops \u2014 tutti i tuoi 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 tra qualche anno. cgi-bin<\/code>, oldbrowse<\/code> e pl<\/code>\u00a0\u2014 tutto questo rivela frammenti di informazione su come lo facciamo ora. Se usi una pagina per cercare un documento, ottieni un risultato altrettanto scadente:<\/p>\n
Rapporto del gruppo di lavoro sulla crittografia e teoria della codifica<\/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
\nQuesto titolo pubs\/1998 offrir\u00e0 a qualsiasi futuro servizio di archivio una buona chiave per comprendere come 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 l'NSF o qualsiasi altra organizzazione che gestir\u00e0 l'archivio.<\/p>\n
Non pensavo che gli URL dovessero essere permanenti \u2014 ci sono state URN, giusto?<\/h4>\n
\nProbabilmente questo \u00e8 uno degli effetti collaterali peggiori della discussione sulle URN. Alcuni pensano che, a causa delle ricerche su uno spazio dei nomi pi\u00f9 permanente, possano trattare con superficialit\u00e0 i link interrotti, credendo che \u00able URN risolveranno tutto\u00bb. Se sei una di queste persone, lascia che ti deluda.<\/p>\n
La maggior parte degli schemi URN che ho visto sembrano essere un identificatore di autorit\u00e0 seguito da una data e una stringa a scelta oppure solo da una stringa a scelta. Questo \u00e8 molto simile a un URI HTTP. In altre parole, se pensate che la vostra organizzazione sar\u00e0 in grado di creare URN a lungo termine, dimostratelo ora utilizzandole per i vostri URI HTTP. Non c'\u00e8 niente nell'HTTP che renda il vostro URI instabile. Solo la vostra organizzazione. Create un database che mappa l'URN del documento con il nome attuale del file e permettete al server web di utilizzarlo per il recupero effettivo dei file.<\/p>\n
Se sei arrivato a questo punto, se non hai tempo, denaro e contatti per sviluppare un software, puoi dichiarare la seguente giustificazione:<\/p>\n
Volevamo farlo, ma semplicemente non abbiamo gli strumenti necessari.<\/h4>\n
\nPuoi davvero provare empatia per questo. Sono completamente d'accordo. Ci\u00f2 che devi fare \u00e8 far s\u00ec che il server web elabori immediatamente l'URI persistente e restituisca il file, dovunque esso sia attualmente archiviato nel tuo attuale sistema di file complesso. Vuoi conservare tutti gli URI in un file come verifica e mantenere costantemente aggiornato il database. Vuoi mantenere le relazioni tra le diverse versioni e traduzioni dello stesso documento, oltre a conservare una registrazione indipendente del checksum per garantire la protezione contro la corruzione del file causata da errori accidentali. E i server web non dispongono di queste funzionalit\u00e0 di default. Quando vuoi creare un nuovo documento, il tuo editor ti chiede di impostare l'URI.<\/p>\n
Hai bisogno della possibilit\u00e0 di modificare la propriet\u00e0, l'accesso al documento, il livello di sicurezza a livello di archivio e altro nello spazio URI senza cambiare l'URI.<\/p>\n
Tutto \u00e8 troppo brutto. Ma risolveremo la situazione. In W3C utilizziamo la funzionalit\u00e0 Jigedit (server Jigsaw per la modifica), che tiene traccia delle versioni, e stiamo sperimentando con gli 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 W3C, compresa questa: quindi fai ci\u00f2 che dico, non ci\u00f2 che faccio.<\/p>\n
Perch\u00e9 dovrei preoccuparmi di questo?<\/h1>\n
\nQuando cambi URI sul tuo server, non puoi mai dire con certezza chi avr\u00e0 i collegamenti all'URI precedente. Potrebbero essere collegamenti da normali pagine web. Segnalibri sulla tua pagina. L'URI potrebbe essere stato annotato ai margini di una lettera a un amico.<\/p>\n
Quando qualcuno clicca su un link e questo non funziona, di solito perde fiducia nel proprietario del server. \u00c8 anche deluso, sia emotivamente che concretamente, per l'impossibilit\u00e0 di raggiungere il suo obiettivo.<\/p>\n
Molte persone si lamentano costantemente di link non funzionanti, e spero che il danno sia evidente. Spero sia anche chiaro il danno reputazionale per il mantenitore del server dove il documento \u00e8 scomparso.<\/p>\n
Allora, cosa devo fare? Progetta l'URI<\/h1>\n
\n\u00c8 responsabilit\u00e0 del webmaster identificare URI che possano essere utilizzati tra 2 anni, 20 anni o 200 anni. Per questo ci vogliono pianificazione, organizzazione e determinazione.<\/p>\n
Le URI cambiano se le informazioni in esse cambiano. \u00c8 molto importante come le progettate. (Cosa, progettare URI? Devo progettare le URI? S\u00ec, dovete pensarci). Progettare significa principalmente evitare qualsiasi informazione nelle URI.<\/p>\n
La data di creazione del documento - la data di emissione delle URI - \u00e8 qualcosa che non cambier\u00e0 mai. \u00c8 molto utile per separare le richieste che utilizzano il nuovo sistema da quelle che utilizzano il vecchio sistema. \u00c8 un buon punto di partenza per le URI. Se su un documento \u00e8 indicata una data, anche se il documento sar\u00e0 rilevante in futuro, \u00e8 un buon inizio.<\/p>\n
L'unica eccezione \u00e8 la pagina che \u00e8 intenzionalmente l'\u00abultima\u00bb versione, per esempio, per tutta l'organizzazione o una sua grande parte.<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/latest\/<\/pre>\n
\nQuesta \u00e8 l'ultima colonna di Money Daily nella rivista Money. La principale ragione per cui non \u00e8 necessaria una data in questo URI \u00e8 che non ci sono motivi per mantenere un URI che sopravviver\u00e0 alla rivista. Il concetto di Money Daily svanir\u00e0 quando Money scomparir\u00e0. Se desideri 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 sempre la stessa cosa per tutta la durata di pathfinder.com. Ci sono duplicati di \"98\" e un inutile \".html\", ma per il resto sembra un URI solido.<\/p>\n
Cosa lasciare da parte<\/h4>\n
\nNiente! A parte la data di creazione, mettere qualsiasi informazione nell'URI ti espone in qualche modo a problemi.<\/p>\n