Sartomiki.net

Web e HTTP
Una pagina web è costituita da oggetti definiti dal linguaggio HTML. Ogni oggetto è raggiungibile tramite un URL (indirizzo). Il protocollo applicativo per il web è HTTP, che si basa su un sistema client/server. HTTP usa TCP per il trasferimento sulla porta 80. Il client apre connessione con servitore, che ha il compito di accettarla. I messaggi vengono scambiati tra browser e web-server. HTTP non tiene memoria delle richieste precedenti (è stateless). Nella versione HTTP1.0  si spedisce solo oggetto sulla connessione (non persistente), con HTTP1.1 è invece possibile inviare più oggetti. Il tempo di risposta di HTTP è uguale a due volte il Round Trip Time (RTT) sommato al tempo della trasmissione. In HTTP1.0 ogni oggetto deve "sprecare" un tempo di 2 RTT di connessione, nella versione persistente la connessione non viene chiusa e quindi il tempo è di "solo" 1 RTT, in HTTP1.1 si può avere pipeline e si spreca un solo RTT per tutti gli oggetti. Esistono tipicamente due messaggi HTTP:
-REQUEST: composto da GET+POST+HEAD. Per inviare dati a server l'input viene trasmesso o nel corpo o nell'url. A partire da HTTP1.1 abbiamo i metodi PUT e DELETE.

-RESPONSE: composto da STATO+INTESTAZIONE+DATI. I codici di stato più usati sono il 200 (OK), 301 (l'oggetto è stato spostato), 400 (richiesta non compresa), 404 (oggetto non trovato), 505 (Versione HTTP non supportata).

Metodi HTTP
GET: produce il trasferimento della risposta specificata nel campo URL. Se la richiesta è un oggetto da elaborare esso viene elaborato e viene spedito il risultato. Ha diverse varianti.
POST: invia i dati contenuti alla risorsa puntata da URL. Serve per annotare risorsa, inviare parametri, inviare messaggi. Le risposte non devono finire in cache.
HEAD: come get ma la risposta contiene solo intestazioni e non è condizionata
PUT: richiede creazione URL non contenuto preso dall'entità inviata. In caso di corrispondenza sovrascrive.
DELETE: richiede la cancellazione di URL e del suo contenuto.
OPTIONS: richiede le opzioni disponibili, le risposte non devono finire in cache, se url "*" si chiedono le opzioni server.
TRACE: Invoca un loop-back. Non contiene entità e serve da verifica.
CONNECT: metodo per proxy.

Campi intestazione
DATE
PRAGMA, indica si o no cache.
MIME-VERSION
AUTH, contiene le credenziali per ottenere autorizzazione
FROM, contiene MAILBOX di chi origina la richiesta
REFERER, contiene URI risorsa da cui si è ottenuto URI della richiesta
USER AGENT (UA), nome e versione dello UA
IF-MODIFIED-SINCE, è una data per aggiornare la cache che indica di aggiornarla se non è stata modificata l'ultima volta dopo quella data
IF-UNMODIFIED-SINCE, l'opposto del precedente
IF-MATCH, la risposta è positiva se il TAG della risorsa corrisponde a quello di uno della lista
IF-NONE-MATCH, il contrario del precedente
ACCEPT-CHARSET, indicano i tipi preferiti
ACCEPT-ENCODING, indica le codifiche accettate
ACCEPT-LANGUAGE. indica le lingue accettate
MAX-FORWARDS, il numero massimo di sistemi intermedi che possono essere attraversati
HOST, la risposta deve essere ottenuta dall'host specificato

Campi entità
ALLOW, metodi ammessi
CONTENT-CODING, codifica (compress, gzip, deflate, identity)
CONTENT-LANGUAGE, lingua
EXPIRES, data scadenza
CONTENT-TYPE, tipo informazione
CONTENT-LENGHT, lunghezza informazione
LAST MODIFIED, data ultima modifica

Formato risposte
STATO: formato da CODE (1xx: riservato, 3xx: incompleto, 4xx: errore nella richiesta, 5xx: errore nell'esecuzione) e da una STRINGA, che spiega il codice
TIPO: generale, di risposta, di entità
ENTITA'
Le risposte contengono:
LOCATION: l'URI esatto
SERVER: Software usato e versione del server che da la risposta
RETRY-AFTER: tempo minimo per ripetere la richiesta
WWW-AUTH: è usato con il 401 e serve a richiedere all'utente l'ID e la PASS.
VIA: registra il percorso della richiesta
WARNING: contiene il nome di chi ha generato il messaggio e il suo testo.
CONTENT-LOCATION: URI alternativo attraverso il quale è possibile trovare la stessa risorsa.

Trasferimento frammentato
Il corpo di una risorsa può essere mandato in maniera frammentata, mediante il parametro transfer coding settato su CHUNCKED. In questo modo si possono spedire risorse create dinamicamente man mano che vengono prodotte, senza dover aspettare il loro effettivo completamento. Nel caso di risorse frammentate esse hanno intestazioni di fondo. Ciascun frammento contiene:
-lunghezza
-parametri (opzionali)
-CRLF (padding)
-DATI
Un utente può chiedere di ricevere solo i dati relativo ad un determinato range di valori