_________________________________________________________________ RFC 1945 in a few words -aka- HTTP/1.0 very small Reference Guide by --[ fritz ]-- _________________________________________________________________ -------[ Intro Questo non vuol essere un documento sostitutivo alla RFC 1945, neanche un riassunto, chiamiamola solo una "guida di riferimento", con un suntino del protocollo http con cui il client (browser, netcat, telnet, spider o chi per esso) comunica col server richiedendo pagine e inviando dati. Quindi maggior attenzione sara' data al lato client, che e' quello che genericamente interessa di piu'. Lo scrivo perche' innanzitutto serve a me in questo momento, ma anche sperando che possa servire a qualcun altro, e non sarebbe una cosa malvagia, credo, se ogni volta che qualcuno si dovesse trovare a fare dei lavoretti o studi del genere buttasse per iscritto qualche riga da mettere a disposizione per tutti gli alti. Ok, detto questo, a mo' di intro, passo al nocciolo. La comunicazione client-server tra il browser che stiamo utilizzando e il sito che andiamo a visitare avviene, ovviamente, dopo una richiesta del client formulata in 2 modi possibili, seguendo questa sintassi: Simple-Request --> "GET" SP Request-URI CRLF Full-Request --> Request-Line *( General-Header | Request-Header | Entity-Header ) CRLF [ Entity-Body ] La sintassi potrebbe sembrare un po' ostica, ma se si legge l'inizio della RFC e' spiegato tutto: -le parti tra parentesi tonda vengono considerati come una unica parte -le parti tra parentesi quadre sono da considerarsi opzionali -le parti separate tra il carattere "|" sono da considerarsi elementi di un'operazione logica di OR, quindi ( a | A ) vale sia "a" che "A" -il carattere "*" prima di qualsiasi elemento significa indefinite ripetizioni di quello che viene dopo (da zero a infinito compresi) Se prima dell'asterisco e' presente un numero, questo rappresenta il numero minimo di ripetizioni di cio' che segue l'asterisco. -CRLF significa "carriage return + line feed", brutalmente significa "enter", "return" o "invio" che dir si voglia :) -SP significa banalmente spazio, ovvero il carattere " " o %20 ---------------------------- Simple-Request ---------------------------- E' il modo piu' semplice di comunicare col server, e serve solo per inviare richieste di invio informazioni, come potrebbe essere la richiesta di vedere una pagina html, o un file. Avviene in una sola riga, e con solo 2 parole, il "GET" e il nome della pagina da vedere, comprensivo o meno di riferimento relativo (o anche assoluto), per esempio potrebbe essere: GET index.html oppure GET /pub/misc/RFC/1000-1500/eps/moana.jpg Per inviare un POST bisogna usare il secondo metodo. ---------------------------- Full-Request ---------------------------- Come gia' visto e' formata da queste parti: Request-Line *( General-Header | Request-Header | Entity-Header ) CRLF [ Entity-Body ] Dopo il chiaramento della sintassi di qualche riga piu' sopra si potrebbe riscrivere il formato in questo modo umanamente piu' comprensibile: -------------------------------------------------------------------------- richiesta iniziale numero a piacere di header appartenenti ai 3 gruppi: General-Header, Request-Header, Entity-Header linea vuota opzionalmente --> Entity-Body -------------------------------------------------------------------------- Andiamo a vedere ora nello spcifico qual e' la sintassi esatta per queste righe. -------[ Request-Line - richiesta iniziale Il suo formato e' questo: Request-Line = Method SP Request-URI SP HTTP-Version CRLF In cui: -Method sta per GET, HEAD, POST o extension method (di questo pero' non tratto); -Request-URI sta per l'indirizzo della pagina che volete vedere o che state usando per un FORM, quindi anche l'indirizzo di un cgi potrebbe essere; -HTTP-Version e' la versione del protocollo, se mettete HTTP/1.0 va praticamente sempre bene; -SP come gia' detto indica banalmente uno spazio, e CRLF un "invio". Quindi un esempio potrebbe essere: GET index.html HTTP/1.0 oppure ancora POST /cgi-bin/sms.cgi HTTP/1.0 e giusto per rompere le palle un altro esempio HEAD http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0 -------[ General-Header Sono header (qui sto traducendo letteralmente) che possono essere utilizzati sia nelle richieste che nell'invio di dati. Un esempio e' l'header DATE, che rappresenta l'ora e la data alla quale la richiesta e' stata scritta. Oppure l'header Pragma, che serve per includere istruzioni precise per qualunque programma/demone che sta in mezzo alla connessione. Meglio di cosi' non riesco a descriverlo :) Un esempio: Pragma: no-cache serve per dire all'applicazione che dovrebbe poi forwardare la richiesta al server (quindi un eventuale proxy, per esempio) di farlo ugualmente anche se in cache e' presente una copia di cio' che e' stato richiesto, quindi utile se non indispensabile nel caso di invio di dati tramite POST -------[ Request-Header Servono al client per inviare ulteriori informazioni al server. Nell'RFC 1945 ne sono illustrati 5: Authorization --> Authorization: credentials From --> From: mailbox (es: From: webmaster@w3.org) [NB: il browser non dovrebbe inviarlo senza previa conferma] If-Modified-Since --> If-Modified-Since: data [es: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT, serve [per scaricare una pagina con GET solo se e' stata modificato dopo la data indicata] Referer --> Referer: web_address [serve per sapere da quale pagina si e' seguito il link per arrivare alla pagina corrente ] User-Agent --> User-Agent: client_information [contiene informazioni sul nome e la versione del browser utilizzato] -------[ Entity-Header Sono degli header opzionali che contengono informazioni sulle informazioni inviate dopo i vari header, ovvero l'Entity-Body: Allow --> Allow: metodo ["metodo" puo' essere GET e HEAD. Non e' permesso usarlo nelle richieste di tipo POST] Content-Encoding --> Content-Encoding: content-coding [per indicare quali tipi di codifica sono ammessi, es: Content-Encoding: x-gzip] Content-Length --> Content-Length: 1*DIGIT [indica la lunghezza del dell'informazione inviato, Es: Content-Length: 3495 Ricordo che 1*DIGIT significa "almeno una cifra"] Content-Type --> Content-Type: media-type [indica il tipo di dati che sono stati inviati al server es: Content-Type: text/html] Expires --> Expires: [indica la data dopo la quale l'informazione inviata non e' piu' valida, es: Expires: Thu, 01 Dec 1994 16:00:00 GMT] Last-Modified --> Last Modificated: [indica l'ora e la data -traduco letteralmente- alla quale il client crede che cio' che ha richiesto e' stato modificato per l'ultima volta] extension-header --> header personalizzati, o non indicati nel protocollo ufficiale -------[ Header addizionali Oltre a quelli gia' citati e ne sono molti altri addizionali, come per esempio l'"Accept:" che indica al server una lista di informazioni e tipologie di dati che sono accettate dal client. Per esempio ci sono: Accept: text/html, text/plain, application/applefile, application/x-metamail-pat Accept: image/gif, application/postscript, */*;q=0.01 Accept-Encoding: gzip, compress Accept-Language: it -------[ Entity-Body Rappresenta l'informazione che viene inviata sia dal client sia dal server. Nel caso del server rappresenta cio' che e' stato richiesto preventivamente da un GET, nel caso del client potrebbe essere, per esempio, il contenuto del form che si sta inviando, del bottone premuto, ecc ecc. La sua presenza, dato che e' opzionale, e' segnalata al server tramite gli Entity-Header visti sopra, che ne definiscono formato e codifica, quindi devono essere sempre presenti se si invia qualcosa. Il form viene inviato secondo una precisa sintassi: una stringa unica contenente tutti i campi e il valore assegnatogli, separati dal carattere "&". Per esempio se nella pagina che stiamo visitando c'e' un form di questo tipo: -----------
Campo1 Campo2
----------- e noi scriviamo "Obluraschi? eddai...." nel Campo1 e "Puppamelo! ahahah!" nel Campo2, alla pressione del bottone INVIA il browser mandera' il FORM secondo questa sintassi (privata dei vari header che spesso non servono) ------------------------------------------------------- POST /cgi-bin/ie.cgi HTTP/1.0 Content-type: application/x-www-form-urlencoded Content-length: 56 text1=Obluraschi?%20eddai....&text2=Puppamelo!%20ahahah! ------------------------------------------------------- Andando ad analizzare la richiesta inoltrata, si vede nella prima riga la richiesta nel formato "full" e un paio di Entity-Header, uno che definisce il formato, e un'altro che indica la lunghezza dei dati inviati. Poi una riga vuota e infine il form compilato, con ogni voce messa accanto al nome della sua casella separata da un "=", e le voci tra di loro separate dal carattere "&". Ultima cosa: non si possono usare gli spazi, quindi vengono convertiti nella sequenza "%20". Le 7 righe sopra pero' non sono solo un estrapolato dele informazioni inviate, ma possono anche essere da sole, in quanto contengono tutto il minimo necessario per eseguire un invio di tipo POST, gli altri header in questo caso sarebbero superflui. Quindi se noi le inviassimo tramite telnet o netcat al sito che ci interessa, simuleremmo l'invio di tali dati tramite browser. Basta solo scrivere quelle 7 righe in un file, per esempio "in.txt", e poi digitale al promp: nc www.host.it 80 < in.txt In questo modo, per esempio, con qualche riga di script in piu' si puo' scrivere un client per inviare sms tramite portali come gsmbox.com senza aprire nemmeno una volta il vostro /lynx/netscape/IE/opera/mosaic ecc ecc ---------------------------- HEAD REQUEST ---------------------------- Per ultima cosa, giusto per dare una parvenza di completezza a questo articoletto, mancano 2 parole sul metodo HEAD. Infatti il GET serve per inviare una richiesta per una pagina, una immagine, o cmq un qualsiasi tipo di informazione, POST serve per inviare dati, e HEAD e' molto simile a GET, solo che il server non risponde con l'Entity-Body (che per il server potrebbe essere una pagina html) ma solo con informazioni relative a questo. ------------------------------------- GESTIONE DEGLI ERRORI ------------------------------------- Ultimissima cosa e' la raccolta dei codici di errori, un copy and paste direttamente dalla RFC: o 1xx: Informational - Not used, but reserved for future use o 2xx: Success - The action was successfully received, understood, and accepted. o 3xx: Redirection - Further action must be taken in order to complete the request o 4xx: Client Error - The request contains bad syntax or cannot be fulfilled o 5xx: Server Error - The server failed to fulfill an apparently valid request Status-Code = "200" ; OK | "201" ; Created | "202" ; Accepted | "204" ; No Content | "301" ; Moved Permanently | "302" ; Moved Temporarily | "304" ; Not Modified | "400" ; Bad Request | "401" ; Unauthorized | "403" ; Forbidden | "404" ; Not Found | "500" ; Internal Server Error | "501" ; Not Implemented | "502" ; Bad Gateway | "503" ; Service Unavailable | extension-code ---------------------------------------------- Chiusura, riferimenti e saluti ---------------------------------------------- Ok, la piccola guida e' finita, e come ogni altra che si rispetti, ecco un paio di link che potrebbero risultare utili http://www.w3.org/ http://www.faqs.org/rfcs/ Per ogni chiarimento, correzione, invito a bere una birra (valido per entrambi i sessi, ma ovviamente in special modo per LEI :) ), mi trovare su fritz@spippolatori.com. --[ fritz ]-- Club SpiPPoLaTorI www.spippolatori.com