Per accedere a qualsiasi risorsa di rete, è necessario sapere dove si trovano e come accedervi. Il World Wide Web utilizza uno schema di indirizzamento e identificazione standardizzato, tenendo conto dell'esperienza nell'indirizzare e identificare e-mail, Gopher, WAIS, telnet, ftp, ecc. - URL, Localizzatore di risorse uniformi.
URI(Uniform Resource Identifier) (RFC 2396, agosto 1998) è una stringa di caratteri compatta utilizzata per identificare una risorsa astratta o fisica. Una risorsa è intesa come qualsiasi oggetto che appartiene a un determinato spazio. Include e sovrascrive gli URL precedentemente definiti (RFC 1738 / RFC 1808) e gli URN (RFC 2141, RFC 2611).
L'URI è progettato per identificare in modo univoco qualsiasi risorsa.
Alcuni sottoinsiemi di URI:
URNA(Uniform Resource Name) - Un URI "urn:" privato con un sottoinsieme del "namespace" che deve essere univoco e immutabile anche quando la risorsa non esiste più o non è disponibile.
Si presume che, ad esempio, il browser sappia dove cercare questa risorsa.
Sintassi:
urn: namespace: data1.data2, more-data, dove namespace definisce come vengono utilizzati i dati dopo il secondo ":".
Esempio di URNA:
urna: ISBN: 0-395-36341-6
ISBN - classificatore tematico per editori
0-395-36341-6 - un numero specifico dell'argomento di un libro o di una rivista
Al ricevimento dell'URN, il programma client passa all'ISBN (la directory "Classificatore topico per editori" su Internet). E ottiene una decrittazione del soggetto numero "0-395-36341-6" (ad esempio: "chimica quantistica").
L'URN è ampiamente utilizzato nelle reti P2P (come edonkey).
Esempio URN che punta a un'immagine del disco Adobe Photoshop v8.0 sulla rete edonkey:
urn: ed2k: // | file | AdobePhotoshopv8.0.iso | 940769280 | | /
ed2k - indica la rete
Adobe Photoshop v8.0.iso - nome file
940769280 - dimensione in byte
- identificatore di file (calcolato utilizzando una funzione hash)
URL Uniform Resource Locator:
URL(Uniform Resource Locator, RFC 1738) è un localizzatore di risorse unificato (locator), un modo standardizzato di registrare l'indirizzo di una risorsa sul WWW e su Internet. L'URL ha una struttura flessibile ed estensibile per indicare la posizione delle risorse sulla rete nel modo più naturale possibile, che identifica una risorsa in base a come vi si accede (ad esempio, la sua "posizione in rete") piuttosto che identificarla per nome o altri attributi di quella risorsa.
Esempi di URL:
http://www.ipm.kstu.ru/index.php
ftp://www.ipm.kstu.ru/
Per rappresentare l'indirizzo viene utilizzato un set limitato di caratteri ASCII.
Forma generale gli indirizzi possono essere rappresentati in questo modo:
<схема>://<логин>:<пароль>@<хост>:<порт>/<полный-путь-к-ресурсу >
schema di accesso alle risorse: http, ftp, gopher, mailto, news, telnet, file, man, info, whatis, ldap, wais, ecc.
Password per il login- nome utente e password utilizzati per accedere alla risorsa
ospite- il nome di dominio dell'host o il suo indirizzo IP.
Porta- porta host per la connessione
percorso completo per la risorsa - chiarire le informazioni sulla posizione della risorsa (dipende dal protocollo).
Esempi di URL:
http://example.com # richiesta per la pagina iniziale predefinita
http://www.example.com/site/map.html # richiede una determinata pagina in una determinata directory
http://example.com:81/script.php # connettersi a una porta non standard
http://example.org/script.php?key=value # richiesta con passaggio di parametri allo script
ftp: // utente: [e-mail protetta]# connettersi al server ftp con autorizzazione
http://192.168.0.1/example/www # connettersi all'indirizzo di rete
file: ///srv/www/htdocs/index.html # apri file locale
gopher: //example.com/1 # connettersi al server gopher
URL: gli Uniform Resource Locator descrivono in modo esplicito come raggiungere un oggetto.
L'avvento degli URL è un'innovazione significativa su Internet. Tuttavia, dal momento della sua invenzione fino ai giorni nostri, lo standard URL ha un grave inconveniente: può utilizzare solo un set limitato di caratteri, anche meno che in ASCII: lettere, numeri e solo qualche segno di punteggiatura-.
Se vogliamo usare caratteri cirillici, o geroglifici, o, diciamo, caratteri specifici della lingua francese nell'URL, allora i caratteri di cui abbiamo bisogno devono essere ricodificati in un modo speciale.
Sulla Wikipedia in russo, devi vedere esempi di codifica URL ogni giorno, poiché la lingua russa utilizza caratteri cirillici. Ad esempio, una riga come questa:
http://ru.wikipedia.org/wiki/Microcredit
URL codificato come:
http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D1%80%D0%B5%D0%B4%D0 % B8% D1% 82
Questa conversione avviene in due fasi: in primo luogo, ogni carattere cirillico è codificato in Unicode (UTF-8) in una sequenza di due byte, quindi ogni byte di questa sequenza è scritto in notazione esadecimale:
M → D0 e 9C →% D0% 9C
e → D0 e B8 →% D0% B8
k → D0 e BA →% D0% BA
p → D1 e 80 →% D1% 80, ecc.
Ciascuno di questi codici byte esadecimali è preceduto da un segno di percentuale (%) in base alla specifica dell'URL, da cui il termine inglese "codifica percentuale", che indica come i caratteri sono codificati negli URL e negli URI.
Poiché le lettere di tutti gli alfabeti, ad eccezione dell'alfabeto latino di base, subiscono tale trasformazione, l'URL con parole nella stragrande maggioranza delle lingue (ad eccezione di inglese, italiano, latino) potrebbe diventare illeggibile per una persona.
Tutto questo è in conflitto con il principio di internazionalismo, proclamato da tutte le principali organizzazioni su Internet, inclusi il W3C e l'ISOC. Questo problema dovrebbe essere risolto dallo standard IRI (International Resource Identifier) - identificatori di risorse internazionali in cui sarebbe possibile utilizzare i caratteri Unicode senza problemi e che quindi non violerebbero i diritti di altre lingue.
Altri schemi URL
Schema HTTP.
Lo schema specifica il suo identificatore, indirizzo macchina, porta TCP, percorso nella directory del server, variabili e loro valori, etichetta.
Sintassi:
http: // [
http - nome schema
utente - nome utente
host - nome host
porta - numero di porta
domanda (<имя-поля>=<значение>{&<имя-поля>=<значение>) - stringa della domanda
Definito in RFC 2068. Per impostazione predefinita, porta = 80.
Esempi:
http://ipm.kstu.ru/internet/index.php
Questo è il tipo più comune di URI utilizzato nei documenti WWW. Il nome dello schema (http) è seguito da un percorso costituito dall'indirizzo del dominio della macchina e dall'indirizzo completo del documento HTML nell'albero del server HTTP.
L'indirizzo IP può essere utilizzato anche come indirizzo della macchina:
http://195.208.44.20/internet/index.php
Se il server HTTP è in esecuzione su una porta TCP diversa da 80, ciò si riflette nell'indirizzo:
http://195.208.44.20:8080/internet/index.php
http://195.208.44.20/internet/index.php#metka1
Il carattere "#" separa il nome del documento dal nome del tag.
Le variabili e i loro valori vengono passati come segue:
http://ipm.kstu.ru/internet/index.php?var1=value1&vard2=value2
I valori "var1" e "var2" sono nomi di variabili e "value1" e "value2" sono i loro valori.
Schema FTP
Questo schema consente di indirizzare gli archivi di file FTP.
Sintassi:
ftp: // [
ftp - nome schema
utente - nome utente
password - password utente
host - nome host
porta - numero di porta
url-path - il percorso del file e il file stesso
Definito in RFC 1738. Per impostazione predefinita, porta = 21, utente = anonimo, password = indirizzo e-mail, se il nome è specificato ma la password non lo è, viene richiesto nella finestra di dialogo.
Esempi: ftp://ipm.kstu.ru/students/name/
Per specificare un nome utente e una password, è necessario scriverlo in questo modo:
ftp: // nome: [e-mail protetta]: //ipm.kstu.ru/students/name/
In questo caso, questi parametri sono separati dall'indirizzo della macchina dal simbolo "@" e l'uno dall'altro da due punti.
Schema MAILTO
Questo schema è destinato all'invio di posta.
Sintassi:
posta: [
mailto - nome schema
e-mail-1 (
utente - nome utente
host - nome host
e-mail-2 - secondo indirizzo e-mail
domanda (<имя-поля-заголовка>=<значение>{&<имя-поля-заголовка>=<значение>) - stringa della domanda
mailto: [e-mail protetta]
In questo schema, vengono passati i campi e i loro valori:
mailto: [e-mail protetta]?oggetto = Oggetto_Email & corpo = Testo_quale_sarà_inserito_nella_email
L'indirizzo del destinatario può anche essere scritto come valore del campo to:
mailto: [e-mail protetta]?oggetto = Oggetto_Email & corpo = Testo_quale_sarà_inserito_nella_email
Che cos'è l'HTTP?
Il primo documento (ma non lo standard) è RFC1945 (Hypertext Transfer Protocol - HTTP / 1.0 T. Berners-Lee, R. Fielding, H. Frystyk maggio 1996)
L'ultima versione è RFC2616 (Hypertext Transfer Protocol - HTTP / 1.1 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee giugno 1999)
Hypertext Transfer Protocol è un protocollo di trasferimento ipertestuale, un protocollo di alto livello (vale a dire, livello di applicazione). Utilizzato dal servizio WWW per trasferire pagine Web.
HTTP (HyperText Transfer Protocol, RFC 2616, la versione attuale è HTTP / 1.1) è un protocollo di trasferimento ipertestuale. Questo protocollo era originariamente destinato allo scambio di documenti ipertestuali, ora le sue capacità sono state notevolmente ampliate (in particolare è stato aggiunto il supporto per lo streaming).
HTTP è un tipico protocollo client-server; i messaggi vengono scambiati secondo lo schema "richiesta-risposta" sotto forma di comandi ASCII. Una caratteristica del protocollo HTTP è la possibilità di specificare in una richiesta e una risposta il modo di rappresentare la stessa risorsa tramite vari parametri: formato, codifica, lingua, ecc. È grazie alla possibilità di specificare il metodo di codifica di un messaggio che il client e il server possono scambiare dati binari, sebbene questo protocollo sia testo.
HTTP è un protocollo a livello di applicazione, ma è anche utilizzato come "trasporto" per altri protocolli applicativi come SOAP, XML-RPC, WebDAV.
Il protocollo HTTP definisce una modalità di interazione richiesta-risposta tra un programma client e un programma server all'interno della tecnologia World Rete larga.
Per caricare una pagina Web in un browser client, invia una richiesta a un programma speciale installato sul computer server, chiamato server http, ed elabora i dati ricevuti da esso. In questo caso, la funzione del browser è chiedere al server una pagina specifica, scaricalo e visualizzalo sullo schermo dell'utente. Il server, d'altra parte, accetta la richiesta, cerca il documento richiesto e fornisce al client il contenuto del file trovato o un messaggio di errore se tale file non è stato trovato o l'accesso è stato negato per qualche motivo . Un punto importante per comprendere questo processo è che il server http non analizza il contenuto del documento trasmesso. In parole povere, il server http non si preoccupa di cosa c'è all'interno del file richiesto, lo trasferisce solo al browser e tutto il lavoro sulla strutturazione e sulla visualizzazione delle informazioni ricevute è già preso
La ricerca della pagina richiesta viene effettuata in una directory specifica, che è allocata sul computer server per questo sito - un collegamento a questa directory è presente nell'indirizzo inserito dall'utente. Nel caso in cui si faccia riferimento non a un documento specifico, ma al sito nel suo insieme, il server http sostituisce automaticamente il cosiddetto " pagina iniziale", denominato index.htm o index.html (in alcuni casi, default.htm o default.html). Questo documento deve trovarsi nella directory principale designata per ospitare il tuo sito o, se diversamente specificato, in una directory chiamata WWW. Tutti gli altri file possono essere collocati nella stessa directory o in sottodirectory, il che a volte è conveniente, soprattutto quando il sito contiene più sezioni o titoli tematici.
Oltre alle sottocartelle che crei, in cui sei libero di inserire quasi tutti i contenuti di cui hai bisogno, la directory del server di solito contiene molte altre directory che dovrebbero essere menzionate separatamente. Innanzitutto, questa è la cartella CGI-BIN, dove si trovano gli script CGI e altre applicazioni interattive avviate dal tuo sito, oltre a diverse directory di servizi necessarie per lavoro normale server. Nella fase iniziale, semplicemente non dovresti prestare loro attenzione. A volte nella stessa directory in cui è memorizzato index.html, ci sono una serie di file aggiuntivi: not_found.html - un documento che viene visualizzato se il server http non riesce a trovare il file richiesto dall'utente, vietato.html - viene visualizzato come messaggio di errore, se viene negato l'accesso al documento richiesto e, infine, robots.txt è un file che descrive nello specifico le regole per l'indicizzazione del proprio sito da parte dei motori di ricerca.
Nella maggior parte dei casi, e soprattutto quando si pubblica una home page su server che forniscono hosting gratuito, agli utenti viene negato l'accesso alle directory dei servizi e alla cartella CGI-BIN, inoltre è impossibile modificare il contenuto dei file not_found e protected.html. Questo dovrebbe essere preso in considerazione se prevedi di includere qualsiasi contenuto interattivo nella tua risorsa che richiede almeno la capacità di inserire file in uno dei cartelle di servizio... In alcuni casi, potrebbe essere vietato creare directory nidificate sul server, quindi l'utente dovrà accontentarsi di una sola directory riservata alle proprie esigenze.
Da quanto detto risulta evidente che il browser del client può solo ricevere ed elaborare informazioni dal server, e inserirle e modificarle solo se il caricamento dei file sul server è implementato in base al protocollo HTTP utilizzando appositi script CGI inclusi nell'interfaccia web del server. In tutti gli altri casi, devi utilizzare il cosiddetto server ftp, sul quale puoi trasferire i file necessari tramite appositi software, caricandoli automaticamente nella directory designata per il tuo sito. In entrambi i casi sarà necessario conoscere il proprio nome utente e password per accedere al sistema. Va inoltre ricordato che la maggior parte dei programmi server (in particolare, Apache per piattaforme compatibili con UNIX) distinguono tra caratteri minuscoli e maiuscoli, quindi tutti i nomi dei file e le loro estensioni dovrebbero essere scritti in minuscolo, e sempre in latino, per evitare errori. Quest'ultimo è dovuto alle differenze nell'elaborazione delle codifiche della lingua russa, tipiche di alcuni server.
Il lavoro sul protocollo HTTP è il seguente: il programma client stabilisce una connessione TCP con il server (il numero di porta standard è 80) e gli invia una richiesta HTTP. Il server elabora questa richiesta e invia una risposta HTTP al client.
La comunicazione tra il client e il server Web avviene tramite lo scambio di messaggi. I messaggi HTTP sono suddivisi in richieste da client a server e risposte da server a client.
I messaggi di richiesta e risposta hanno un formato comune. Entrambi i tipi di messaggio hanno questo aspetto: prima viene la riga di inizio, quindi eventualmente uno o più campi di intestazione, chiamati anche semplicemente intestazioni, quindi riga vuota(ovvero una stringa composta dai caratteri CR e LF) che indica la fine dei campi di intestazione, e quindi eventualmente il corpo del messaggio:
linea di partenza
campo di intestazione 1
campo di intestazione 2
campo di intestazione N
corpo del messaggio
Intestazioni del protocollo HTTP
Il formato della riga iniziale del client e del server è diverso e verrà discusso di seguito. Esistono quattro tipi di titoli:
Intestazioni generali (general-header), che possono essere presenti sia nella richiesta che nella risposta;
Intestazioni di richiesta, che possono essere presenti solo in una richiesta;
Intestazioni di risposta, che possono essere presenti solo in una risposta;
Intestazioni di entità che fanno riferimento al corpo di un messaggio e ne descrivono il contenuto.
Ogni titolo è composto da un titolo, due punti ":" e un valore. I titoli più importanti sono riportati nella tabella 1.
Tabella 1
Intestazioni del protocollo HTTP
| Intestazione | Appuntamento |
| Intestazioni oggetto | |
| Permettere | Elenca i metodi supportati dal server |
| Codifica del contenuto | Il modo in cui viene codificato il corpo del messaggio, ad esempio per ridurne le dimensioni |
| Contenuto-Lunghezza | Lunghezza del messaggio in byte |
| Tipo di contenuto | Contiene la designazione del tipo di contenuto MIME della risposta. A seconda del tipo di contenuto, il browser interpreta la risposta come una pagina HTML, un'immagine gif o jpeg, un file da salvare su disco o qualcos'altro e intraprende l'azione appropriata. Alcuni tipi di contenuto: testo/html - testo in formato HTML(pagina web); text / plain - testo normale (simile a "Blocco note"); immagine / jpeg - immagine in Formato JPEG; immagine / gif - lo stesso, in formato GIF; Può anche passare la codifica per i dati di testo. Ad esempio: charset = windows-1251 charset = koi8-rus Content-Length - lunghezza del contenuto della risposta in byte (dimensione del file). Ultima modifica: data e ora dell'ultima modifica del documento. |
| ETag | Un tag risorsa univoco sul server che consente di confrontare le risorse |
| Scade | Data e ora in cui la risorsa sul server verrà modificata e dovrà essere recuperata di nuovo |
| Ultima modifica | Data e ora dell'ultima modifica del contenuto |
| Intestazioni di risposta | |
| Età | Il numero di secondi dopo i quali riprovare la richiesta per ottenere nuovi contenuti |
| Posizione | L'URI della risorsa da consultare per ottenere il contenuto |
| Riprova dopo | Data e ora o numero di secondi dopo i quali la richiesta deve essere ripetuta per ricevere una risposta positiva |
| server | Nome del software del server che ha risposto |
| Intestazioni della richiesta | |
| Accettare | Un elenco dei tipi di contenuto supportati dal browser in ordine di preferenza per questo browser, ad esempio: Accetta: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application / msword, application / vnd.ms-powerpoint, * / * Questo è ovviamente necessario nel caso in cui il server possa servire lo stesso documento in formati diversi. Il valore di questo parametro viene utilizzato principalmente dagli script CGI per generare una risposta adattata per un determinato browser. |
| Accetta-Charset | Codifiche dei caratteri in cui il client può accettare contenuto di testo |
| Accetta-codifica | Il modo in cui il server può codificare il messaggio |
| Ospite | Host e numero di porta da cui viene richiesto il documento |
| If-Modified-Since If-Match If-Nessuno-Match If-Range If-Unmodified-Since | Intestazioni di richiesta per l'accesso condizionale alle risorse |
| Gamma | Richiedi parte di un documento |
| Agente utente | Nome del software client: il valore è il "nome in codice" del browser, ad esempio: Mozilla / 4.0 (compatibile; MSIE 5.0; Windows 95; DigExt) |
| Intestazioni generali | |
| Connessione | Connessione: può essere Keep-Alive e vicina. Keep-Alive significa che dopo l'emissione di questo documento la connessione al server non viene terminata e possono essere emesse più richieste. La maggior parte dei browser funziona in modalità Keep-Alive, poiché consente di "scaricare" una pagina html e immagini in una connessione al server. Una volta impostata, la modalità Keep-Alive viene mantenuta fino al primo errore o fino a quando non viene esplicitamente indicato nella successiva Connection: close request. close - la connessione viene chiusa dopo aver risposto a questa richiesta. |
| Data | Data e ora di formazione del messaggio |
| pragma | Comandi specifici per l'implementazione per il contenuto trasferito |
| Trasferimento-codifica | Metodo di codifica dei messaggi per la trasmissione |
In alcune intestazioni, il valore è data e ora. Devono essere nel formato descritto nella RFC 1123, ad esempio:
Il corpo del messaggio contiene le informazioni effettivamente trasmesse: il carico utile del messaggio. Il corpo del messaggio è una sequenza di ottetti (byte). Il corpo del messaggio può essere codificato, con la codifica specificata nell'intestazione dell'oggetto Content-Encoding.
Un messaggio di richiesta dal client al server è costituito da una riga di richiesta, intestazioni (generale, richiesta, oggetto) e possibilmente un corpo del messaggio.
La riga di richiesta inizia con un metodo, seguito dall'identificatore della risorsa richiesta, dalla versione del protocollo e dai caratteri finali della riga:
<Метод> <Идентификатор> <Версия HTTP>
Metodo specifica il metodo da applicare alla risorsa richiesta. Ad esempio, il metodo GET dice che il client vuole ottenere il contenuto della risorsa. L'identificatore identifica la risorsa richiesta. La versione HTTP è indicata da una riga come questa:
HTTP/<версия>.<подверсия>
Metodi del protocollo HTTP
Diamo un'occhiata ai principali metodi del protocollo HTTP.
Il metodo OPTIONS richiede informazioni sulle opzioni di connessione (ad esempio, metodi, tipi di documenti, codifiche) supportate dal server per la risorsa richiesta. Questo metodo consente al client di definire opzioni e/o requisiti associati alla risorsa, o le capacità del server, senza intraprendere alcuna azione sulla risorsa o avviare un download.
Se la risposta del server non è un messaggio di errore, le intestazioni degli oggetti contengono informazioni che possono essere considerate opzioni di connessione. Ad esempio, l'intestazione Consenti elenca tutti i metodi supportati dal server per una determinata risorsa.
Se l'identificatore della risorsa richiesta è un asterisco ("*"), la richiesta OPTIONS è destinata a rivolgersi al server nel suo insieme.
Se l'identificatore della risorsa richiesta non è un asterisco, la richiesta OPTIONS si applica alle opzioni disponibili durante la connessione alla risorsa specificata.
Il metodo GET permette di ottenere qualsiasi informazione relativa alla risorsa richiesta. Nella maggior parte dei casi, se l'identificatore della risorsa richiesta punta a un documento (ad esempio, documento di testo, immagine grafica, video), il server restituisce il contenuto di questo documento (contenuto del file). Se la risorsa richiesta è un'applicazione (programma) che genera dati, i dati generati vengono restituiti nel corpo del messaggio di risposta e non un'immagine binaria del file eseguibile. Viene utilizzato, ad esempio, durante la creazione di applicazioni CGI. Se l'identificatore della risorsa richiesta punta a una directory (directory, cartella), allora, a seconda delle impostazioni del server, il contenuto della directory (elenco di file) o il contenuto di uno dei file situati in questa directory (di solito index.html o Default.htm). V quest'ultimo caso il nome della cartella può essere specificato sia con il simbolo "/" alla fine, sia senza di esso. Se questo simbolo è assente alla fine dell'identificatore, il server emette una delle risposte con reindirizzamento (con codici di stato 301 o 302).
Distinguere tra "GET condizionale", in cui il messaggio di richiesta include le intestazioni di richiesta If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match o If-Range. Metodo condizionale GET richiede il trasferimento di un oggetto solo se soddisfa le condizioni descritte nelle intestazioni fornite. Il metodo GET condizionale è progettato per diminuire download non necessario rete, poiché consente di non scaricare per la seconda volta i dati già salvati dal cliente.
Viene inoltre fatta una distinzione tra "GET parziale", in cui il messaggio di richiesta include un'intestazione di richiesta Range. Un GET parziale richiede il trasferimento solo di una parte dell'oggetto. Il metodo GET parziale è progettato per ridurre il carico di rete non necessario richiedendo solo una parte dell'oggetto quando l'altra parte è già stata scaricata dal client. Il valore dell'intestazione Range è l'intervallo di byte da ricevere. I byte sono numerati a partire da 0. I byte iniziali e finali dell'intervallo sono separati da un carattere "-". Se è necessario ottenere più intervalli, sono elencati separati da virgole.
Il metodo HEAD è identico a GET, tranne per il fatto che il server non restituisce il corpo del messaggio nella risposta. Le meta informazioni contenute nelle intestazioni HTTP della risposta a una richiesta HEAD sono identiche alle informazioni fornite nella risposta a una richiesta GET. Questo metodo può essere utilizzato per ottenere informazioni sull'oggetto della richiesta senza inoltrare direttamente il corpo dell'oggetto. Il metodo HEAD viene spesso utilizzato per testare i collegamenti ipertestuali.
Il metodo POST viene utilizzato per una richiesta, in cui il server indirizzato riceve i dati inclusi nel corpo del messaggio (oggetto) della richiesta e li invia per l'elaborazione all'applicazione specificata come risorsa richiesta. POST è progettato per implementare le seguenti funzioni in modo generale:
Annotazione delle risorse esistenti;
Invio di un messaggio a una bacheca elettronica (BBS), newsgroup, mailing list o simili gruppi di articoli;
Passare un blocco di dati, come il risultato di un input in un modulo, a un processo di elaborazione;
Esecuzione di query su database (DB);
Infatti, la funzione svolta dal metodo POST è determinata dall'applicazione puntata dall'ID della risorsa richiesta. Insieme al metodo GET, il metodo POST viene utilizzato durante la creazione di applicazioni CGI. Il browser può formulare richieste con il metodo POST durante l'invio dei moduli. Per questo, l'elemento FORM Documento HTML contenente il modulo deve avere un attributo METHOD con un valore POST.
Un'azione POST può eseguire un'azione sul server e non passare alcun contenuto come risultato. In questo caso, a seconda che la risposta includa o meno un corpo del messaggio che descrive il risultato, il codice di stato nella risposta può essere 200 (OK) o 204 (Nessun contenuto).
Se la risorsa è stata creata sul server, la risposta contiene un codice di stato 201 (Creato) e include l'intestazione della risposta Posizione.
Il corpo del messaggio, che viene trasmesso in una richiesta con il metodo PUT, viene salvato sul server e l'identificatore della risorsa richiesta sarà l'identificatore del documento salvato. Se l'identificatore della risorsa richiesta punta a una risorsa già esistente, l'oggetto incluso nel corpo del messaggio viene trattato come una versione modificata della risorsa situata sul server. Se viene creata una nuova risorsa, il server ne informa l'agente utente con una risposta con un codice di stato 201 (Creato).
La differenza fondamentale tra i metodi POST e PUT è significato diverso l'identificativo della risorsa richiesta. L'URI nella richiesta POST identifica la risorsa che sta gestendo l'oggetto incluso nel corpo del messaggio. Questa risorsa può essere un'applicazione che riceve dati. Al contrario, l'URI in PUT richiesta identifica l'oggetto incluso nella richiesta come corpo del messaggio, ovvero l'interprete assegna l'URI dato alla risorsa inclusa.
Il metodo DELETE chiede al server di eliminare una risorsa che ha l'identificatore richiesto. Una richiesta con questo metodo può essere rifiutata dal server se l'utente non dispone dell'autorizzazione per eliminare la risorsa richiesta.
Il metodo TRACE viene utilizzato per restituire la richiesta inoltrata a livello di protocollo HTTP. Il destinatario della richiesta (server Web) invia il messaggio ricevuto al client come corpo di un oggetto di risposta con un codice di stato 200 (OK). Una richiesta TRACE non deve contenere un corpo del messaggio.
TRACE consente al client di vedere cosa sta ricevendo il server dall'altra parte e di utilizzare tali dati per test o diagnostica.
Se la richiesta ha esito positivo, la risposta contiene l'intero messaggio di richiesta nel corpo del messaggio di risposta e l'intestazione dell'oggetto Content-Type è "message / http".
Codici di risposta
Dopo aver ricevuto e interpretato il messaggio di richiesta, il server risponde con un messaggio di risposta HTTP.
La prima riga della risposta è la Status-Line. Consiste in una versione del protocollo, un codice di stato numerico, una frase esplicativa, separata da spazi e caratteri finali di fine riga:
<Версия HTTP> <Код состояния> <Поясняющая фраза>
La versione del protocollo ha lo stesso significato della richiesta.
L'elemento Status-Code è un codice intero a tre cifre (tre cifre) del risultato della comprensione e della soddisfazione della richiesta. Reason-Phrase è una breve descrizione testuale del codice di stato. Il codice di stato è per l'elaborazione del software e la frase esplicativa è per gli utenti.
La prima cifra del codice di stato identifica la classe della risposta. Le ultime due cifre non hanno un ruolo specifico nella classificazione. Ci sono 5 valori per la prima cifra:
1xx: Codici informazioni - richiesta ricevuta, elaborazione continua.
2xx: Codici di successo: l'azione è stata ricevuta, compresa ed elaborata correttamente.
3xx: Codici di reindirizzamento: è necessario intraprendere ulteriori azioni per completare la richiesta.
4xx: Codici di errore client - La richiesta ha un errore di sintassi o non può essere completata.
5xx: Codici di errore del server: il server non è in grado di soddisfare una richiesta valida.
Le frasi di motivazione per ogni codice di stato sono elencate in RFC 2068 e sono consigliate, ma possono essere sostituite con equivalenti senza influire sul protocollo. Ad esempio, nelle versioni localizzate in lingua russa dei server HTTP, queste frasi vengono sostituite da quelle russe. La tabella 2 elenca i codici di risposta del server HTTP.
Tavolo 2
Codici di risposta del server HTTP
| Codice | Frase esplicativa secondo RFC 2068 | Frase esplicativa equivalente in russo |
| 1xx: Codici informativi | ||
| Continua | Continua | |
| 2xx: codici di successo | ||
| ok | ok | |
| Creato | Creato da | |
| Nessun contenuto | Nessun contenuto | |
| Reimposta contenuto | Reimposta contenuto | |
| Contenuto parziale | Contenuto parziale | |
| 3xx: codici di reindirizzamento | ||
| trasferito temporaneamente | Spostato temporaneamente | |
| Non modificato | Non modificato | |
| 4xx: codici di errore del cliente | ||
| Brutta richiesta | Richiesta danneggiata | |
| non autorizzato | non autorizzato | |
| Non trovato | Non trovato | |
| operazione non permessa | Il metodo non è consentito | |
| Richiedi timeout | Tempo scaduto per la richiesta | |
| Conflitto | Conflitto | |
| Lunghezza richiesta | Lunghezza richiesta | |
| Entità richiesta troppo grande | L'oggetto della richiesta è troppo grande | |
| 5xx: codici di errore del server | ||
| Server interno Errore | Errore interno server | |
| Non implementato | Non implementato | |
| Servizio non disponibile | Il servizio non è disponibile | |
| Versione HTTP non supportata | Versione HTTP non supportata |
La barra di stato è seguita dalle intestazioni (generale, risposta e oggetto) e possibilmente dal corpo del messaggio.
Uno di funzioni essenziali un server web fornisce l'accesso a una parte del file system locale. Per fare ciò, nelle impostazioni del server viene specificata una determinata directory, che è la radice di questo server. Per pubblicare un documento, ovvero realizzarlo a disposizione degli utenti chi ha "visitato" questo server (avendo effettuato una connessione con esso tramite il protocollo HTTP), è necessario copiare questo documento nella directory principale del server Web o in una delle sue sottodirectory. Quando ci si connette tramite il protocollo HTTP, viene creato un processo sul server con diritti utente, che, di regola, non esiste nella realtà, ma è creato appositamente per visualizzare le risorse del server. Configurando i diritti e le autorizzazioni di questo utente, è possibile controllare l'accesso alle risorse Web.
Diamo un'occhiata all'esempio più semplice di una richiesta HTTP. Se nella finestra dell'indirizzo del browser digitiamo l'indirizzo http://yandex.ru, il browser determinerà l'indirizzo IP del server yandex.ru e gli invierà la seguente richiesta HTTP sulla porta 80:
OTTIENI http://yandex.ru/ HTTP / 1.0
Accetta: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*
Accetta-Lingua: ru
Cookie: yandexuid = 2464977781018373381
Agente utente: Mozilla / 4.0 (compatibile; MSIE 5.5; Windows 98)
Host: yandex.ru
Referente: narod.ru
Connessione proxy: Keep-Alive
La richiesta viene inviata in chiaro modulo di testo... La parte più importante della richiesta si trova nella prima riga: questo è il tipo di richiesta (GET), l'indirizzo URL del documento richiesto (http://yandex.ru) e la versione del protocollo HTTP (HTTP / 1.0 ). Di seguito i parametri della richiesta. Ogni riga corrisponde a un parametro. La riga inizia con il nome del parametro, seguito da due punti e dal valore del parametro.
Accetta è il tipo di dati che il browser può accettare (codificato MIME).
Accept-Language è la lingua preferita in cui il browser vuole accettare i dati. User-Agent - il tipo di programma che ha inviato la richiesta.
Host - Nome DNS (o IP) dell'host a cui è indirizzata la richiesta.
Cookie - cookie (dati che sono stati salvati dal server sul disco locale del client durante l'ultima visita a questo host).
Referer - l'host dalla cui pagina stiamo inviando la richiesta. Quindi, ad esempio, se siamo sulla pagina http://narod.ru e facciamo clic sul collegamento http: //yandex.ru lì, la richiesta verrà inviata all'host yandex.ru e al campo di richiesta referer conterrà il nome host di narod.ru.
Il set di parametri di query non è fisso. Oltre a quanto sopra, potrebbero esserci altri parametri.
I parametri più interessanti sono referer e cookie. Questi parametri vengono utilizzati principalmente per autenticare l'utente al server.
OTTIENI richiesta può contenere dati trasmessi dal client al server. Vengono passati direttamente attraverso l'URL utilizzando il protocollo CGI. I dati sono separati dall'URL da un "?" e sono collegati con il segno “&”:
OTTENERE
Questo tipo di trasferimento dati al server è conveniente, ma presenta limitazioni di volume. Non è possibile trasferire quantità eccessive di dati tramite l'URL. A tal fine, esiste un altro tipo di richiesta: una richiesta POST. Una richiesta POST è molto simile a una richiesta GET, con l'unica differenza che i dati nella richiesta POST vengono trasmessi separatamente dall'intestazione della richiesta stessa:
Il corpo della richiesta deve essere separato dall'intestazione da una riga vuota. Se il server incontra una stringa vuota in una richiesta POST, tutto ciò che segue considera il corpo della richiesta (dati trasmessi). Nota quanto segue: il formato dei dati nel corpo della richiesta POST è arbitrario. Sebbene il formato CGI sia più comunemente usato, non è richiesto. Inoltre, una richiesta POST non richiede un corpo della richiesta e può anche trasferire dati tramite un URL.
Oltre al formato CGI, a volte il cosiddetto. formato multiparte (il formato dei dati trasmessi è determinato dal parametro Content-Type):
Browser moderni contengono strumenti per gli sviluppatori web per ottenere alcune informazioni sulle richieste di post inviate. Se hai bisogno di guardare le intestazioni di solo un paio di richieste, usarle sarà più facile e veloce rispetto ad altri metodi.
Se stai usando Firefox, puoi usare la sua console web. Visualizza le intestazioni delle richieste e il contenuto dei cookie trasmessi. Per avviarlo, apri il menu del browser, fai clic sulla voce "Sviluppo Web" e seleziona "Console Web". Nel pannello che appare, attiva il pulsante "Rete". Inserisci il nome del metodo - inserisci nel campo del filtro. A seconda dei tuoi obiettivi, fai clic sul pulsante del modulo di invio richiesta richiesta oppure aggiorna la pagina La console visualizza la richiesta inviata. Cliccaci sopra con il mouse per vedere maggiori dettagli.
Browser di Google Chrome dispone di potenti strumenti di debug. Per utilizzarli, clicca sull'icona con l'immagine di una chiave inglese, quindi apri la voce "Configura e gestisci" Google Chrome". Seleziona "Strumenti" e avvia "Strumenti per sviluppatori". Nella barra degli strumenti, seleziona la scheda Rete e invia la tua richiesta. Trova la richiesta richiesta nell'elenco e cliccaci sopra per studiarne i dettagli.
Il browser Opera dispone di strumenti di sviluppo integrati per Opera Dragonfly. Per avviarli, fai clic con il pulsante destro del mouse sulla pagina richiesta e seleziona la voce del menu contestuale "Ispeziona elemento". Vai alla scheda Network Tools Developer e invia la tua richiesta. Trovalo nell'elenco ed espandilo per esaminare le intestazioni e le risposte del server.
Internet Explorer 9 contiene un kit chiamato F12 Developer Tools che fornisce informazioni dettagliate sulle richieste eseguite. Si avviano premendo il tasto F12 o utilizzando il menu "Servizio" contenente l'omonima voce. Per visualizzare la richiesta, vai alla scheda "Rete". Trova la query specificata nel riepilogo e fai doppio clic per espandere i dettagli.
Browser Chrome e Internet Explorer 9 contengono strumenti integrati che consentono di esaminare in dettaglio una richiesta di posta inviata. Per tutti i dettagli usali o Firefox con plugin installato Firebug. È molto utile per esaminare frequentemente le query, ad esempio durante il debug di siti.
Se vuoi vedere una richiesta inviata da un programma diverso da un browser, usa il debugger HTTP Fiddler. Funziona come un server proxy e intercetta le richieste da qualsiasi programma e fornisce anche informazioni molto dettagliate sulle loro intestazioni e contenuti.
Un URI (Uniform Resource Identifier) è una stringa compatta di caratteri utilizzata per identificare una risorsa astratta o fisica. Una risorsa è intesa come qualsiasi oggetto che appartiene a un determinato spazio. La necessità di un URI è stata compresa dagli sviluppatori WWW sin dall'inizio del sistema, poiché avrebbe dovuto combinare in un unico ambiente informativo significa utilizzare vari metodi per identificare le risorse informative. È stata sviluppata una specifica che includeva chiamate a FTP, Gopher, WAIS, Usenet, E-mail, Prospero, Telnet, X.500 e ovviamente HTTP (WWW). Di conseguenza, è stata sviluppata una specifica universale che consente di espandere l'elenco delle risorse indirizzabili a causa dell'emergere di nuovi schemi.
Dove vengono utilizzati gli URI sono collegamenti ipertestuali scritti in tag e ... La grafica incorporata è anche indirizzata dalla specifica URI nei tag e
L'emergere di URN deriva dal desiderio di indirizzare porzioni MIME di un messaggio di posta. Principi di costruzione di un indirizzo WWW. L'URI si basava sui seguenti principi:
· Estensibilità: i nuovi schemi di indirizzamento dovrebbero adattarsi facilmente alla sintassi URI esistente.
· Completezza: quando possibile, qualsiasi schema esistente dovrebbe essere descritto utilizzando un URI.
· Leggibilità - l'indirizzo doveva essere facilmente leggibile dall'utente, che è generalmente tipico della tecnologia WWW - i documenti, insieme ai collegamenti, possono essere sviluppati in un normale editor di testo.
Prima di esaminare i vari schemi di rappresentazione degli indirizzi, ecco un esempio di un semplice URI:
http://polyn.net.kiae.su/polyn/index.html
I due punti sono preceduti dall'identificatore dello schema di indirizzo - "http". Questo nome è separato da due punti dal resto dell'URI, chiamato percorso. In questo caso il percorso è costituito dall'indirizzo di dominio della macchina su cui è installato il server HTTP e dal percorso dalla radice dell'albero del server al file "index.html". Oltre alla notazione URI completa mostrata sopra, ce n'è una semplificata. Presuppone che al momento dell'utilizzo molti parametri dell'indirizzo della risorsa siano già stati definiti (protocollo, indirizzo della macchina nella rete, alcuni elementi del percorso). Sotto tali presupposti, l'autore delle pagine ipertestuali può indicare solo il relativo indirizzo della risorsa, es. un indirizzo relativo a determinate risorse sottostanti.
Un URL (Uniform Resource Locator) è un sottoinsieme di schemi URI che identifica una risorsa in base alla modalità di accesso (ad esempio, la sua "posizione sul Web") anziché identificarla per nome o altri attributi di quella risorsa. L'URL descrive esplicitamente come raggiungere l'oggetto.
Sintassi:
schema = "http" | "Ftp" | "Gopher" | "Mailto" | "Notizie" | "Telnet" | "File" | "Uomo" | "Informazioni" | "Cos'è" | "Ldap" | "Wais" | ...- nome schema
schema – specifico – parte- dipende dallo schema. I valori esadecimali possono essere utilizzati nella parte specifica dello schema nella forma:% 5f. Gli ottetti non stampabili devono essere codificati: 00-1F, 7F, 80-FF.
Esempi di URL:
Http://www.ipm.kstu.ru/index.php
Ftp://www.ipm.kstu.ru/
URN (Uniform Resource Name) è un URI "urn:" privato con un sottoinsieme del "namespace" che deve essere univoco e immutabile anche quando la risorsa non esiste più o è inaccessibile.
Si presume che, ad esempio, il browser sappia dove cercare questa risorsa.
Sintassi: urn: namespace: data1.data2, altro – data dove namespace definisce come vengono utilizzati i dati dopo il secondo ":".
Esempio di URNA:
urna: ISBN: 0-395-36341-6
ISBN - classificatore tematico per editori,
0-395-36341-6 - un numero specifico dell'argomento di un libro o di una rivista
Al ricevimento dell'URN, il programma client passa all'ISBN (la directory "Classificatore topico per editori" su Internet). E ottiene una decrittazione del soggetto numero "0-395-36341-6" (ad esempio: "chimica quantistica"). L'URN è relativamente nuovo, l'HTML non è incluso nelle versioni attuali e i servizi di directory non sono ancora stati sviluppati, quindi l'URN non è così diffuso come l'URL.
Schemi di indirizzamento delle risorse Internet
Esistono 3 schemi per l'indirizzamento delle risorse Internet. Lo schema specifica il suo identificatore, indirizzo macchina, porta TCP, percorso nella directory del server, variabili e loro valori, etichetta.
Schema HTTP... Questo è il layout di base per il WWW. Lo schema contiene il suo identificatore, indirizzo della macchina, porta TCP, percorso nella directory del server, criterio di ricerca ed etichetta.
Sintassi: http: // [
http- nome del circuito
utente- Nome utente
parola d'ordine- password utente
ospite- Nome host
porta- numero di porta
url – percorso- il percorso del file e il file stesso
interrogazione (<имя–поля>=<значение>{&<имя–поля>=<значение>) - stringa della domanda
Per impostazione predefinita, porta = 80.
Ecco alcuni esempi di URI per lo schema HTTP:
http://polyn.net.kiae.su/polyn/manifest.html
Questo è il tipo più comune di URI utilizzato nei documenti WWW. Il nome dello schema (http) è seguito da un percorso costituito dall'indirizzo del dominio della macchina e dall'indirizzo completo del documento HTML nell'albero del server HTTP.
L'indirizzo IP può essere utilizzato anche come indirizzo della macchina:
http://144.206.160.40/risk/risk.html
Se il server HTTP è in esecuzione su una porta TCP diversa da 80, ciò si riflette nell'indirizzo:
http://144.206.130.137:8080/altai/index.html
http://polyn.net.kiae.su/altai/volume4 .html # first
Schema FTP... Questo schema consente di indirizzare gli archivi di file FTP dai programmi client del World Wide Web. In questo caso, il programma deve supportare il protocollo FTP. In questo schema, è possibile specificare non solo il nome dello schema, l'indirizzo dell'archivio FTP, ma anche l'ID utente e persino la sua password.
Sintassi: ftp: // [
ftp- nome del circuito
utente- Nome utente
parola d'ordine- password utente
ospite- Nome host
porta- numero di porta
url – percorso- il percorso del file e il file stesso
Per impostazione predefinita, porta = 21, utente = anonimo, password = indirizzo email.
Questo schema è più spesso utilizzato per accedere agli archivi FTP pubblici:
ftp://polyn.net.kiae.su/pub/0index.txt
In questo caso viene registrato un collegamento all'archivio "polyn.net.kiae.su" con l'identificatore "anonymous" o "ftp" (accesso anonimo). Se è necessario specificare l'ID utente e la sua password, è possibile farlo davanti all'indirizzo della macchina:
ftp: // nessuno: [e-mail protetta]/ utenti / locale / pub
In questo caso, questi parametri sono separati dall'indirizzo della macchina dal simbolo @ e l'uno dall'altro da due punti.
Schema TELNET... Questo schema viene utilizzato per accedere alla risorsa in modalità terminale remoto. In genere, il client richiama un programma aggiuntivo su telnet. Quando si utilizza questo schema, è necessario specificare un ID utente, è consentita una password.
Sintassi: telnet: // [
telnet- nome del circuito
utente- Nome utente
parola d'ordine- password utente
ospite- Nome host
porta- numero di porta
Per impostazione predefinita, porta = 23.
Esempio: telnet: // nome: [e-mail protetta]
In realtà si accede a risorse pubbliche e l'identificatore e la password sono generalmente noti, ad esempio si possono trovare nei database Hytelnet.
telnet: // ospite: [e-mail protetta]
Come puoi vedere dagli esempi precedenti, la specifica dell'indirizzo della risorsa URI è abbastanza generale e ti consente di identificare praticamente qualsiasi risorsa su Internet. In questo caso, il numero di risorse può essere ampliato creando nuovi schemi.
Servizio WWW
Servizio WWW (World Wide Web) - progettato per lo scambio di informazioni ipertestuali, costruito secondo lo schema "client-server". Il browser (Internet Explorer, Opera...) è un client multiprotocollo e un interprete HTML. E come un tipico interprete, il client svolge funzioni diverse a seconda dei comandi (tag). La gamma di queste funzioni include non solo il posizionamento di testo sullo schermo, ma anche lo scambio di informazioni con il server durante l'analisi del testo HTML ricevuto, cosa che si vede più chiaramente quando si visualizzano immagini grafiche incorporate nel testo.
Il server HTTP (Apache, IIS...) gestisce le richieste del client per ottenere il file. All'inizio il servizio WWW si basava su tre standard:
· HTML (HyperText Markup Lan – guage) - linguaggio di markup ipertestuale dei documenti;
· URL (Universal Resource Locator) - un modo universale di indirizzare le risorse sulla rete;
· HTTP (HyperText Transfer Protocol) - un protocollo per lo scambio di informazioni ipertestuali.
Schema di funzionamento del server WWW
Un server WWW è una parte di una rete globale o intranet che consente agli utenti della rete di accedere ai documenti ipertestuali che si trovano su questo server. Per interagire con il server WWW, un utente di rete deve utilizzare un software specializzato - un browser (dal browser inglese) - un visualizzatore.
Diamo un'occhiata più da vicino allo schema operativo del server WWW:
1. L'utente della rete avvia un browser, le cui funzioni includono:
· Stabilire la connessione con il server;
· Ottenere il documento richiesto;
· Visualizzazione del documento ricevuto;
· Risposta alle azioni dell'utente - accesso a un nuovo documento. Dopo aver avviato il browser, su comando dell'utente, o stabilisce automaticamente una connessione con il server WWW specificato e gli invia una richiesta per ricevere il documento specificato.
2. Il server WWW cerca il documento richiesto e restituisce i risultati al browser.
3. Il browser, ricevuto il documento, lo mostra all'utente e attende la sua reazione. Opzioni possibili:
· Inserimento dell'indirizzo di un nuovo documento;
· Stampa, ricerca, altre operazioni sul documento corrente;
· Attivazione (pressatura) di aree speciali del documento ricevuto, denominate link e associate all'indirizzo del nuovo documento. Nel primo e nel terzo caso c'è appello per un nuovo documento.
URI (Identificatore uniforme delle risorse) è un identificatore di risorsa unificato (uniforme). L'URI è una stringa di caratteri che consente di identificare qualsiasi risorsa: documento, immagine, file, servizio, casella di posta elettronica, ecc. Parliamo innanzitutto, ovviamente, delle risorse di Internet e del World Wide Web . Un URI fornisce un modo semplice ed estensibile per identificare le risorse. L'estensibilità dell'URI significa che esistono già diversi schemi di identificazione all'interno di un URI e altri verranno creati in futuro.
Relazione tra URI, URL e URN
Diagramma di Venn che mostra i sottoinsiemi dello schema URI: URL e URN.
L'URI è un URL, un URN o entrambi.
- Un URL è un URI che, oltre a identificare una risorsa, fornisce anche informazioni sulla posizione di tale risorsa.
- Un URN è un URI che identifica solo una risorsa in uno specifico spazio dei nomi (rispettivamente, in un contesto specifico), ma non ne indica la posizione. Ad esempio, URN urn: ISBN: 0-395-36341-1 è un URI che punta a una risorsa (libro) 0-395-36341-1 nello spazio dei nomi ISBN, ma a differenza di un URL, l'URN non punta al posizione di quella risorsa: non dice in quale negozio puoi acquistarla o su quale sito web scaricarla.
Poiché l'URI non indica sempre come ottenere una risorsa, a differenza di un URL, ma la identifica solo, questo rende possibile descrivere risorse tramite RDF (Resource Description Framework) che non possono essere ottenute via Internet (ad esempio, una persona, un'auto, una città, ecc.).
Storia
Nel 1990, a Ginevra, in Svizzera, all'interno delle mura del Consiglio europeo per la ricerca nucleare, lo scienziato britannico Tim Berners-Lee ha inventato l'URL del localizzatore di risorse. Poiché l'URL è il sottoinsieme di URI più comunemente utilizzato, il 1990 è considerato l'anno di nascita dell'URI. Ma, in senso stretto, il concetto di URI è stato documentato solo nel giugno 1994 in RFC 1630.
La nuova versione dell'URI è stata definita nel 1998 nella RFC 2396, contemporaneamente la parola universale nel titolo è stato cambiato in Uniforme.
svantaggi
L'URL è stata un'innovazione fondamentale su Internet, quindi i principi dell'URI sono stati documentati per garantire la piena compatibilità degli URL. Da qui deriva il grande svantaggio degli URI, che ereditano dagli URL. In un URI, come in un URL, può essere utilizzato solo un insieme limitato di caratteri latini e segni di punteggiatura (anche meno che in ASCII). In altre parole, se vogliamo usare caratteri cirillici, o geroglifici, o, diciamo, caratteri francesi specifici, nell'URI, dovremo codificare l'URI nello stesso modo in cui Wikipedia codifica gli URL con caratteri Unicode. Ad esempio, una riga come questa:
https://ru.wikipedia.org/wiki/Cyrillic
URL codificato come:
https://ru.wikipedia.org/wiki/%D0%9A%D0%B8%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D1%86%D0%B0
Poiché le lettere di tutti gli alfabeti, ad eccezione dell'alfabeto latino utilizzato in inglese, subiscono tale trasformazione, gli URI con parole in altre lingue (anche europee) perdono la capacità di essere percepiti dalle persone. E questo è in palese contraddizione con il principio di internazionalismo, proclamato da tutte le principali organizzazioni di Internet, inclusi il W3C e l'ISOC. Questo problema è destinato a essere risolto dallo standard IRI (ing. Identificatore di risorse internazionalizzate) - identificatori di risorse internazionali in cui sarebbe possibile utilizzare i caratteri Unicode senza problemi e che non violerebbero i diritti di altre lingue. Inoltre, il creatore dell'URI, Tim Berners-Lee, ha affermato che il sistema dei nomi di dominio che sta alla base degli URL è una decisione sbagliata, costringendo le risorse a un'architettura gerarchica che non è adatta al web ipertestuale.
struttura dell'URI
URI = [schema ":"] gerarchico - parte [ "?" richiesta] [frammento "#"]
In questa voce:
schema
schema per accedere a una risorsa (spesso indica un protocollo di rete), ad esempio http, ftp, file, ldap, mailto, urn
parte gerarchica
contiene dati, solitamente organizzati in forma gerarchica, che, se combinati con dati in una componente non gerarchica inchiesta, servono per identificare la risorsa nell'ambito dello schema URI. Generalmente parte-gerarchica contiene il percorso della risorsa (ed, eventualmente, davanti ad essa, l'indirizzo del server su cui si trova) o l'identificatore della risorsa (nel caso di URN).
Inchiesta
questo componente URI opzionale è descritto sopra.
Frammento
(anche un componente opzionale)
Consente di identificare indirettamente una risorsa secondaria facendo riferimento alla risorsa primaria e specificando informazioni aggiuntive. Una risorsa secondaria identificabile può essere una parte o un sottoinsieme del primario, una sua rappresentazione o un'altra risorsa definita o descritta da tale risorsa.
Analisi della struttura dell'URI. Per il cosiddetto "parsing" degli URI (eng. analisi), ovvero per scomporre gli URI nelle loro parti costitutive e la loro successiva identificazione, è più conveniente utilizzare il sistema delle espressioni regolari, che è ora disponibile in quasi tutti i linguaggi di programmazione moderni. Il modello seguente è consigliato per l'analisi degli URI in RFC 3986:
Questo modello include 9 gruppi indicati sopra da numeri (per ulteriori informazioni su modelli e gruppi, vedere Espressioni regolari), che analizzano in modo più completo e accurato una tipica struttura URI, dove:
- gruppo 2 - schema,
- gruppo 4 - fonte,
- gruppo 5 - percorso,
- gruppo 7 - richiesta,
- gruppo 9 - frammento.
Quindi, se, utilizzando questo modello, analizziamo, ad esempio, un tipico URI:
http://www.ics.uci.edu/pub/ietf/uri/#Related
quindi i 9 gruppi di modelli sopra daranno rispettivamente i seguenti risultati:
- http:
- //www.ics.uci.edu
- www.ics.uci.edu
- / pub / ietf / uri /
- nessun risultato
- nessun risultato
- #Imparentato
- Imparentato
Esempi di URI:
URI assoluti
- https://ru.wikipedia.org/wiki/URI
- ftp://ftp.is.co.za/rfc/rfc1808.txt
- file: // C: \ UserName.HostName \ Projects \ Wikipedia_Articles \ URI.xml
- file: /// C: /file.wsdl
- file: ///Users/John/Documents/Projects/Web/MyWebsite/about.html
- ldap: /// c = GB? objectClass? one
- mailto: [e-mail protetta]
- sorso: [e-mail protetta]
- notizie: comp.infosystems.www.servers.unix
- dati: testo / semplice; set di caratteri = iso-8859-7,% be% be% be
- telefono: + 1-816-555-1212
- telnet: //192.0.2.16: 80 /
- urn: oasis: nomi: specifica: docbook: dtd: xml: 4.1.2
2) URI relativi
- /relativo/URI/con/assoluto/percorso/alla/risorsa.txt
- //example.org/scheme-relative/URI/with/absolute/path/to/resource.txt
- relativo / percorso / a / risorsa.txt
- ../../../resource.txt
- risorsa.txt
- /resource.txt#frag01
- # frag01
[stringa vuota] - equivale all'analisi dell'identificatore da parte del parser con il risultato [stringa vuota], ovvero il collegamento porta all'oggetto predefinito nello schema predefinito
Servizio DNS
DNS sta per Domain Name System. I nomi di dominio DNS sono sinonimi di indirizzi IP, proprio come i nomi nella rubrica del telefono sono sinonimi di numeri di telefono. Sono simbolici, non numerici; sono più convenienti per la memorizzazione e l'orientamento; portano un carico semantico. www.irnet.ru → Tabelle DNS → 193.232.70.36 Anche i nomi di dominio sono univoci, ad es. non ci sono due nomi di dominio identici nel mondo. I nomi di dominio, a differenza degli indirizzi IP, sono facoltativi, vengono acquistati in aggiunta.
Riso. 2. Gerarchia nel DNS.
Univoci sono anche gli indirizzi che sono indicati sulle buste quando si consegnano lettere per posta ordinaria. Non ci sono paesi al mondo con gli stessi nomi. E se a volte i nomi delle città vengono ripetuti, in combinazione con la divisione in unità amministrative più grandi come distretti e regioni, diventano unici. E i nomi delle strade non dovrebbero essere ripetuti all'interno della stessa città. Pertanto, l'indirizzo, in base a nomi geografici e amministrativi, identifica in modo univoco la destinazione. I domini hanno una gerarchia simile. I nomi di dominio sono separati l'uno dall'altro da punti: lingvo.yandex.ru, krkime.com.
Il DNS ha le seguenti caratteristiche:
- Amministrazione distribuita... Diverse persone o organizzazioni sono responsabili di diverse parti della gerarchia.
- Distribuzione dell'archiviazione delle informazioni... Ogni nodo della rete deve necessariamente memorizzare solo i dati che sono inclusi nel suo area di responsabilità e (possibilmente) indirizzi server DNS di root.
- Cache delle informazioni... Nodo può essere memorizzare alcuni dati al di fuori della propria area di responsabilità per ridurre il carico sulla rete.
- Struttura gerarchica, in cui tutti i nodi sono combinati in un albero e ciascun nodo può determinare indipendentemente il lavoro dei nodi di livello inferiore, oppure delegare(trasferirli) ad altri nodi.
- Prenotazione... Per l'archiviazione e la manutenzione dei propri nodi (zone) sono (solitamente) più server, separati sia fisicamente che logicamente, il che garantisce la sicurezza dei dati e la prosecuzione del lavoro anche in caso di guasto di uno dei nodi.
Livelli di dominio. Ci sono tre livelli di domini.
Domini primo o primo livello sono divisi in due gruppi:
1) Questi sono domini con affiliazione territoriale, ad esempio: .ru .by .ua .de .us, ecc. Cioè, questi sono domini assegnati a un determinato paese. Con loro, puoi, ad esempio, determinare a quale paese appartiene un determinato sito.
2) Il secondo gruppo di domini di primo livello sono domini con uno scopo specifico. Ad esempio: .com - per le organizzazioni commerciali, .info - per i siti informativi, .tv - per le società televisive, ecc. Questi domini possono essere utilizzati per determinare il focus specifico del sito. Anche se, a dire il vero, ultimamente sono sempre più utilizzati in qualsiasi modo e spesso non aderiscono al loro scopo.
I domini di primo livello non possono essere utilizzati come indirizzo del tuo sito. Servono per creare domini secondo livello , quindi, su uno qualsiasi dei domini di primo livello, puoi registrare un dominio di secondo livello. Un dominio di secondo livello è costituito dai seguenti elementi: www.nome_sito.dominio di primo livello. Ad esempio: www.webmastermix.ru. Si consiglia di utilizzare nomi di dominio di secondo livello per l'indirizzo del sito. Sono meglio letti e ricordati dalle persone, oltre che percepiti dai motori di ricerca. Pertanto, la maggior parte dei siti ha nomi di dominio a questo livello.
Inoltre, ci sono domini terzo livello ... Vengono creati sulla base di domini di secondo livello. Il dominio di terzo livello ha questo aspetto: www.forum.webmastermix.ru. Dopo aver registrato un dominio di secondo livello, puoi creare autonomamente sulla base di esso tutti i domini di terzo livello che desideri. Puoi registrare un nome di dominio per il tuo sito utilizzando servizi speciali.
TECNOLOGIE WEB: HTML, JAVASCRIPT
La prima parte del blocco didattico del suddetto argomento è stata dedicata alle tecnologie Internet. Ora stiamo iniziando a studiare le tecnologie utilizzate nel World Wide Web, o tecnologie web.
Innanzitutto, è necessario comprendere i concetti di base delle tecnologie web: sito web e pagina web. Una pagina Web è l'unità logica minima del World Wide Web, che è un documento identificato in modo univoco da un URL univoco. Un sito web è una raccolta di pagine web tematicamente correlate situate sullo stesso server e di proprietà dello stesso proprietario. In un caso particolare, un sito web può essere rappresentato da una singola pagina web. Il World Wide Web è la raccolta di tutti i siti web.
La base dell'intero World Wide Web è il linguaggio di markup ipertestuale HTML - Hyper Text Markup Language (Fig. 3). Serve per il markup logico (semantico) di un documento (pagina web). A volte viene utilizzato in modo improprio per controllare il modo in cui il contenuto delle pagine Web viene visualizzato sullo schermo di un monitor o durante l'output su una stampante, il che contraddice fondamentalmente l'ideologia adottata sul World Wide Web.
Riso. 3. Tecnologie web
I fogli di stile a cascata (CSS) hanno lo scopo di controllare la visualizzazione del contenuto nelle pagine web. I CSS sono simili in molti modi agli stili utilizzati nel popolare elaboratore di testi, Word.
I linguaggi di scripting sono utilizzati per aggiungere dinamismo alle pagine web (menu a tendina, animazione). Il linguaggio di scripting standard sul world wide web è JavaScript. Il nucleo di JavaScript è ECMAScript.
HTML, CSS, JavaScript sono linguaggi con i quali puoi creare qualsiasi sito web complesso. Ma questo è solo un supporto linguistico, mentre nei browser i documenti sono rappresentati come una raccolta di oggetti, molti dei quali sono il browser object model (BOM). Il modello a oggetti del browser è univoco per ciascun modello e pertanto sorgono problemi durante la creazione di applicazioni tra browser. Pertanto, il Web Consortium ha proposto il Document Object Model (DOM), che è il modo standard per rappresentare le pagine Web utilizzando una raccolta di oggetti.
La sintassi del moderno HTML è descritta utilizzando l'Extensible Markup Language. XML ti consentirà di creare i tuoi linguaggi di markup simili all'HTML sotto forma di DTD. Esistono molti linguaggi di questo tipo: per rappresentare formule matematiche e chimiche, conoscenza, ecc.
Come puoi vedere da quanto sopra, tutte le tecnologie web sono strettamente interconnesse. Comprendere questo fatto renderà più facile comprendere lo scopo di un particolare meccanismo utilizzato per creare applicazioni web.
La posta elettronica (e-mail, e-mail, dalla posta elettronica inglese) è una tecnologia e i servizi che fornisce per inviare e ricevere messaggi elettronici (chiamati "lettere" o "e-mail") su una rete di computer distribuita. La principale differenza rispetto ad altri sistemi di messaggistica è la possibilità di consegna ritardata e un sistema sviluppato di interazione tra server di posta indipendenti.
La posta elettronica consente di inviare e ricevere messaggi, rispondere automaticamente alle lettere dei corrispondenti utilizzando i loro indirizzi, inviare copie della lettera a più destinatari contemporaneamente, inoltrare la lettera ricevuta a un altro indirizzo, utilizzare nomi logici anziché indirizzi (numerici o nomi di dominio), creare diverse sottosezioni della casella di posta per tutti i tipi di corrispondenza, includere file di testo in lettere, utilizzare il sistema "riflettori di posta" per condurre discussioni con un gruppo di corrispondenti, ecc. Per inviare un messaggio postale via e-mail è necessario indicare l'indirizzo della casella di posta. La casella di posta di un abbonato e-mail è un'area del disco rigido di un server di posta riservata all'utente.
Lo sviluppo della tecnologia Internet ha portato all'emergere di moderni protocolli di messaggistica, che offrono grandi opportunità per l'elaborazione delle lettere, una varietà di servizi e facilità d'uso. Quindi, ad esempio, il protocollo SMTP, che funziona sul principio client-server, è progettato per inviare messaggi da un computer al destinatario. In genere, l'accesso al server SMTP non è protetto da password, quindi qualsiasi server noto sulla rete può essere utilizzato per inviare e-mail. A differenza dei server per l'invio di lettere, l'accesso ai server per l'archiviazione dei messaggi è protetto da password. Pertanto, è necessario utilizzare il server o il servizio in cui esiste l'account. Questi server utilizzano i protocolli POP e IMAP, che differiscono nel modo in cui archiviano i messaggi.
In accordo con il protocollo POP3, i messaggi che arrivano ad un determinato indirizzo vengono conservati sul server fino a quando non vengono scaricati sul computer durante la sessione successiva. Dopo aver scaricato i messaggi, puoi disconnetterti dalla rete e iniziare a leggere la posta. Pertanto, l'utilizzo della posta POP3 è il più veloce e comodo da usare.
Il protocollo IMAP è conveniente per coloro che utilizzano una connessione permanente alla rete. Anche i messaggi ricevuti dall'indirizzo vengono archiviati sul server, ma, a differenza di POP3, durante il controllo della posta, verranno scaricate prima solo le intestazioni dei messaggi. La lettera stessa può essere letta dopo aver selezionato l'intestazione del messaggio (verrà scaricata dal server). È chiaro che con una connessione dial-up, lavorare con la posta utilizzando questo protocollo porta a inutili perdite di tempo.
Esistono diversi protocolli per la ricezione e il trasferimento della posta tra sistemi multiutente.
Una breve descrizione di alcuni di essi:
1) SMTP (Simple Mail Transfer Protocol)è un protocollo di rete progettato per la trasmissione di posta elettronica in reti TCP/IP, e la trasmissione deve essere necessariamente avviata dal sistema trasmittente stesso.
MTA (Mail Transfer Agent) - l'agente di trasferimento della posta - è il componente principale del sistema di trasferimento della posta Internet, che rappresenta questo computer di rete per il sistema di posta elettronica di rete. In genere, gli utenti non lavorano con l'MTA, ma con il programma MUA (Mail User Agent), un client di posta elettronica. Il principio di interazione è schematicamente mostrato in figura.
2) POP, POP2, POP3 (protocollo postale)- tre protocolli non intercambiabili abbastanza semplici, sviluppati per consegnare la posta a un utente da un server di posta centrale, cancellarla da esso e identificare un utente tramite nome / password. POP include SMTP, utilizzato per trasferire la posta da un utente. I messaggi di posta possono essere ricevuti sotto forma di intestazioni, senza ricevere l'intero messaggio.
Dopo che la connessione è stata stabilita, il protocollo POP3 passa attraverso tre stati consecutivi
- Autorizzazione il cliente passa attraverso la procedura di autenticazione
- La transazione del cliente riceve informazioni sullo stato della cassetta postale, accetta ed elimina la posta.
- L'aggiornamento del server elimina le email selezionate e chiude la connessione.
3) IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1 (Protocollo di accesso ai messaggi Internet) - fornisce all'utente ricche opportunità per lavorare con caselle di posta situate su un server centrale
o IMAP memorizza la posta sul server in directory di file e fornisce anche al client la possibilità di cercare stringhe nei messaggi di posta sul server stesso.
o IMAP2 - utilizzato in rari casi.
o IMAP3 - soluzione incompatibile, non utilizzata.
o IMAP2bis - un'estensione di IMAP2, consente ai server di analizzare i messaggi in una struttura MIME (Multipurpose Internet Mail Extensions), ancora in uso.
o IMAP4 è un IMAP2bis rielaborato e migliorato che può essere utilizzato ovunque.
o IMAP4rev1 - Estende IMAP con un'ampia gamma di funzionalità, incluse quelle utilizzate da DMSP (Distributed Mail System for Personal Computers).
4) ACAP (Application Configuration Access Protocol) - un protocollo sviluppato per funzionare con IMAP4; aggiunge la possibilità di cercare abbonamenti e iscrizioni a bacheche, caselle di posta e viene utilizzato per cercare rubriche.
5) DMSP (o PCMAIL) è un protocollo per la ricezione/invio di posta, la cui particolarità è che l'utente può avere più di una postazione a suo uso. La workstation contiene le informazioni sullo stato della posta, la directory attraverso la quale avviene lo scambio, che, una volta connessa al server, viene aggiornata allo stato corrente sul server di posta.
6) MIME è uno standard che definisce i meccanismi per l'invio di tutti i tipi di informazioni via e-mail, incluso il testo in lingue diverse dall'inglese, per le quali vengono utilizzate codifiche di caratteri diverse dall'ASCII, nonché contenuti binari a 8 bit come immagini, musica, film e programmi.
Lavoro indipendente.
Esegui l'esempio fornito nel testo (dispensa) e salvalo nella tua cartella sul desktop.
9.2. Lavorare con un insegnante:
In caso di difficoltà o azioni errate, contattare l'insegnante per correggere gli errori.
Entro la fine della lezione, mostra all'insegnante una relazione sul lavoro svolto e ottieni un credito per questo lavoro.
9.3. Controllo del livello di conoscenza iniziale e finale:
Test su un computer .
Informazioni simili.
URI dell'identificatore di risorsa uniforme. Gli URI sono conosciuti con molti dei nomi di indirizzi WWW, Universal Document Identifier, URI e infine come una combinazione di Uniform Resource Locator, URL e Uniform Resource Name, URN. HTTP definisce un URL semplicemente come una stringa formattata che identifica una risorsa per nome, posizione o qualsiasi altra caratteristica. 3.2.1 Sintassi generale. Gli URI in HTTP possono essere presentati in forma assoluta URI assoluti o URI relativi relativi ad alcuni URI di base noti, a seconda del contesto del loro utilizzo. La differenza tra le due forme è che gli URI assoluti iniziano sempre con un nome di schema colonizzato da due punti.
URI AbsoluteURI frammento URI relativo schema URI assoluto uchar riservato URI relativo percorso net percorso abs percorso rel percorso rete loc abs percorso abs percorso rel percorso rel percorso percorso params? percorso query fsegment segmento fsegment 1 pchar segmento pchar params param param param pchar schema 1 ALPHA DIGIT net loc pchar? query uchar riservato frammento uchar riservato pchar uchar uchar non riservato escape non riservato ALPHA DIGIT sicuro extra nazionale escape HEX HEX riservato? extra sicuro non sicuro CTL SP nazionale qualsiasi OCTET eccetto ALPHA, DIGIT, ottetti riservati, extra, sicuri e non sicuri I dettagli completi della sintassi e della semantica dell'URL sono contenuti in RFC 1738 e RFC 1808. La normale notazione Backus-Naur include caratteri nazionali non consentiti in URL validi definiti da RFC 1738, poiché i server HTTP consentono a un insieme di caratteri non riservati di rappresentare la porzione di percorso rel degli indirizzi e pertanto i proxy HTTP possono ricevere richieste URI non conformi a RFC 1738. Il protocollo HTTP non impone eventuali restrizioni sulla lunghezza dell'URI... I server devono gestire gli URI di qualsiasi risorsa, di qualsiasi lunghezza, che servono e devono gestire URI di lunghezza illimitata se servono server basati su GET in grado di generare tale URI. Il server DOVREBBE restituire un codice di stato 414 della richiesta URI Too Long, Request-URI Too Long se l'URI è più lungo di quanto il server possa gestire.
I server dovrebbero prestare attenzione agli URI più lunghi di 255 byte perché alcuni client o proxy meno recenti potrebbero non supportare correttamente queste lunghezze. 3.2.2 URL HTTP. Lo schema HTTP viene utilizzato per accedere alle risorse di rete utilizzando il protocollo HTTP. Questa sezione definisce la sintassi e la semantica definite dallo schema per gli URL HTTP. URL http porta host http host percorso abs un nome di dominio valido della macchina o indirizzo IP in notazione decimale puntata come definito nella sezione 2.1 della RFC 1123 porta DIGIT Se la porta è vuota o non specificata, viene utilizzata la porta 80. Ciò significa che la porta identificata la risorsa è ospitata sul server, in attesa di connessioni TCP sulla porta, sull'host specificati e l'URI della risorsa richiesta è il percorso abs. L'uso di indirizzi IP negli URL dovrebbe essere evitato il più possibile dalla RFC 1900. Se il percorso abs non è presente nell'URL, DEVE essere trattato come quando si calcola la risorsa richiesta Request-URI. 3.2.3
Fine del lavoro -
Questo argomento appartiene alla sezione:
Protocollo HTTP 1.1
Secondo RFC 1945, HTTP 1.0 era un miglioramento di questo protocollo, consentiva un formato di messaggi simile a MIME contenente meta-informazioni su quelli trasmessi.Tuttavia, HTTP 1.0 non teneva conto delle peculiarità del lavoro con quelli gerarchici. .. 1.1 ..
Se hai bisogno di materiale aggiuntivo su questo argomento, o non hai trovato quello che stavi cercando, ti consigliamo di utilizzare la ricerca nella nostra base di opere:
Cosa faremo con il materiale ricevuto:
Se questo materiale si è rivelato utile per te, puoi salvarlo nella tua pagina sui social network:
| Tweet |
Tutti gli argomenti di questa sezione:
Terminologia
Terminologia. Connessione di connessione. Canale virtuale livello di trasporto, stabilito tra due programmi ai fini della comunicazione messaggio messaggio. Il modulo principale della comunicazione HTTP, costituito da struttura
Parametri del protocollo
Parametri del protocollo. La versione HTTP.HTTP utilizza uno schema di numerazione principale. minor per indicare la versione del protocollo. La strategia di versionamento del protocollo è progettata per consentire l'invio
Confronto UR
Confronto di UR. I. Quando si confrontano due URI per decidere se corrispondono o meno, il client DOVREBBE utilizzare un confronto ottetto per ottetto con distinzione tra maiuscole e minuscole di questi URI, con
Data completa
Data completa. Le applicazioni HTTP hanno storicamente consentito tre diversi formati per rappresentare le date dell'ora solare, 06 novembre 1994 08 49 37 GMT RFC 822 modificato in RFC 1123 domenica, 06-nov-94 08 49 37 GMT
Set di caratteri
Set di caratteri. HTTP usa la stessa definizione del termine tabella dei codici che è definito per MIME Il termine codebook è usato per fare riferimento a un metodo che utilizza
Codifiche dei contenuti
Codifica dei contenuti, codifica dei contenuti. Il valore di codifica del contenuto indica quale trasformazione di codifica è stata o sarà applicata all'oggetto. Viene utilizzata la codifica del contenuto
Codici di trasferimento
Codici di trasferimento Codici di trasferimento. I valori di codifica di trasferimento vengono utilizzati per indicare una trasformazione di codifica che è stata o dovrebbe essere applicata all'entità-corpo al fine di
Tipi di supporto
Tipi di supporto Tipi di supporto. HTTP utilizza i tipi di media Internet nei campi di intestazione Content-Type e Accept per fornire dati aperti ed estensibili e digitazione del tipo. tipo di supporto t
Canonicalizzazione e valori predefiniti di tipo testo
Canonicalizzazione e valori predefiniti di tipo testo. I tipi di media Internet sono registrati in forma canonica. V caso generale il corpo dell'oggetto trasmesso dal messaggio HTTP deve essere
Tipi in più parti
Tipi in più parti. MIME fornisce una serie di tipi multiparte che formano un pacchetto di uno o più oggetti all'interno del corpo di un singolo messaggio. Tutti i tipi multiparte condividono una sintassi comune, o
Gettoni del prodotto
Token del prodotto. I marcatori di prodotto vengono utilizzati per consentire alle applicazioni di comunicazione di identificarsi con il nome e la versione del software.
Valori di qualità
Valori di qualità. HTTP utilizza brevi numeri in virgola mobile per indicare l'importanza relativa del peso dei vari parametri negoziati. Il peso è una sostanza normalizzata
Tag di lingua Tag di lingua
Tag di lingua Tag di lingua. Il tag della lingua identifica una lingua naturale parlata, scritta o utilizzata in altro modo dalle persone per scambiare informazioni con altre persone. I linguaggi macchina sono
Tag di entità
Tag di entità. Le etichette degli oggetti vengono utilizzate per confrontare due o più oggetti della stessa risorsa richiesta. HTTP 1.1 utilizza etichette di entità nei campi di intestazione ETag
Unità di intervallo Unità di intervallo
Unità di intervallo Unità di intervallo. HTTP 1.1 consente a un client di richiedere solo una parte di un oggetto. HTTP 1.1 utilizza le unità di intervallo nei campi di intestazione Range e Content-Rang
Tipi di messaggi
Tipi di messaggi. I messaggi HTTP sono suddivisi in richieste da client a server e risposte da server a client. Messaggio HTTP Richiesta di risposta Messaggi HTTP 1.1 I messaggi di richiesta e risposta utilizzano un formato generico
Intestazioni dei post
Intestazioni dei post. Campi di intestazione HTTP, che includono campi di intestazione generale, intestazione richiesta, intestazione risposta e intestazione entità-h
Corpo del messaggio
Il corpo del messaggio. Il corpo del corpo del messaggio HTTP, se presente, viene utilizzato per trasmettere il corpo dell'oggetto associato alla richiesta o alla risposta. Il corpo del corpo del messaggio è diverso dal corpo su
Lunghezza del messaggio
La lunghezza del messaggio. Quando un corpo del messaggio è presente in un messaggio, la lunghezza di quel corpo è determinata da uno dei seguenti metodi, in ordine di precedenza 1. Qualsiasi messaggio di risposta che non dovrebbe
Metodo Metodo
Metodo Metodo. Il token del metodo specifica il metodo da applicare alla risorsa identificata dall'URI di richiesta richiesto. Il metodo fa distinzione tra maiuscole e minuscole. Metodo OPZIONI GET HEAD PO
Codice di stato e frase esplicativa
Codice di stato e frase esplicativa. L'elemento Status-Code è un codice intero a tre cifre per il risultato di un tentativo di comprendere ed eseguire una richiesta. Questi codici sono completamente definiti nella sezione
Connessioni persistenti
Connessioni persistenti. Obbiettivo. Prima dell'introduzione delle connessioni persistenti, veniva impostato un URL separato per ogni richiesta URL. Connessione TCP, che ha aumentato il carico su HTTP da allora
Negoziazione di discussione
Negoziazione di discussione. Un server HTTP 1.1 può presumere che un client HTTP 1.1 non supporti una connessione persistente se l'intestazione Connection inviata nella richiesta contiene il token di connessione
Pipelining per la lavorazione del trasportatore
Elaborazione del trasportatore Pipelining. Cliente che supporta connessioni persistenti sa come inoltrare le richieste, ovvero inviare più richieste senza attendere una risposta a ciascuna
Considerazioni pratiche
Considerazioni pratiche. I server in genere hanno un valore di timeout dopo il quale non mantengono una connessione inattiva. I proxy possono impostarlo più in alto
Requisiti per il trasferimento dei messaggi
Requisiti per la trasmissione dei messaggi. Requisiti generali- I server HTTP 1.1 DOVREBBERO mantenere connessioni persistenti e utilizzare meccanismi di controllo del flusso TCP per ridurre i tempi temporanei
Metodi sicuri
Metodi sicuri. I programmatori dovrebbero capire che il software, quando interagisce con Internet, rappresenta l'utente e il programma dovrebbe informare l'utente di qualsiasi azione
Definizione dei codici di stato
Definizione dei codici di stato. Ciascun codice di stato, descritto di seguito, include una descrizione del metodo o dei metodi che può seguire e le meta informazioni richieste nella risposta. 10.1 1xx - Informare
Autenticazione di accesso
Autenticazione di accesso. Per autenticare l'accesso, HTTP fornisce un semplice meccanismo challenge-response che può essere utilizzato da
Schema di autenticazione di base
Schema di autenticazione di base. Lo schema di autenticazione di base si basa sul fatto che l'agente utente deve dimostrare la propria identità utilizzando un ID.
Cache HTTP
Cache HTTP. HTTP è comunemente usato per la distribuzione sistemi di informazione quali prestazioni possono essere migliorate utilizzando le risposte memorizzate nella cache. Il protocollo HTTP 1.1 include p
Correttezza della cache
La correttezza della cache. cache corretta deve rispondere alla richiesta con la risposta più aggiornata, corrispondente alla richiesta, memorizzata dalla cache che soddisfi una delle seguenti condizioni 1. Era valida
Meccanismi di controllo della cache
Meccanismi di controllo della cache. I meccanismi di cache di base nell'ora di scadenza e nel validatore specificati dal server HTTP 1.1 sono direttive implicite
Avvisi espliciti sull'agente utente
Avvisi espliciti sull'agente utente. Molti interpreti consentono agli utenti di sovrascrivere i meccanismi di memorizzazione nella cache di base. Ad esempio, un interprete potrebbe consentire p
Eccezioni alle regole e avvertenze
Eccezioni alle regole e avvertenze. In alcuni casi, l'operatore della cache può configurarlo per restituire risposte scadute anche se non richieste dal client.
Comportamento controllato dal cliente
Comportamento controllato dal cliente. Considerando che il server di origine e, in misura minore, le cache intermedie e il loro contributo all'età della risposta sono la fonte primaria di informazioni sull'obsolescenza
Modello di obsolescenza
Il modello di deprezzamento. Obsolescenza, specificato dal server... La memorizzazione nella cache HTTP funziona al meglio quando le cache possono evitare completamente le richieste al server di origine. Meccanismo primario e
Obsolescenza euristica
Obsolescenza euristica. Poiché i server di origine non indicano sempre tempi di scadenza espliciti, le cache HTTP in genere assegnano tempi di scadenza euristici utilizzando algoritmi che vengono utilizzati
Calcolare l'età
Calcolare l'età. Per sapere se un oggetto nella cache è nuovo, la cache deve sapere se è più vecchio della data di aggiornamento. Host che utilizzano HTTP, in particolare hos
Calcolo dell'obsolescenza
Calcolo dell'obsolescenza. Per decidere se una risposta è fresca o in ritardo, dobbiamo confrontare la sua durata con l'età. L'età viene calcolata utilizzando l'algoritmo descritto nella sezione 13.2.3
Fasi di sviluppo della tradizione esicasta
Fasi di sviluppo della tradizione esicasta. Tradizione esicasta dal greco. termine - pace, silenzio - una certa scuola di pratica spirituale, sviluppatasi dal IV secolo. fino ad oggi. 7 In questo lungo viaggio tempi
