Questa libreria NON è un webserver completo, ma solo una sua parte, il PARSER
Che cosa fa il PARSER?
Esso legge la richiesta del client e ne estrae i dati a poi necessari.
Quando un browser effettua una richiesta, essa può essere una GET, POST, DELETE, PUT ed altre meno usate.
In realtà è solo negli ultimi anni che si usano ampiamente PUT e DELETE, fino ad ora GET e POST facevano da padroni, infatti visto che è il webserver che interpreta la richiesta come vuole, l'uso di una o di un altra è una pura convenzione, nota come REST
In parole povere?
la GET serve per RICHIEDERE uno o più dati (l'eventuale dato o filtri da applicare sulla serie dati si passano via query string)
la POST serve per AGGIORNARE un dato (il riferimento al dato va nella query string, il dato nel corpo)
la PUT serve per CREARE un dato (il riferimento al dato va nella query string, il dato nel corpo)
la DELETE serve per ELIMINARE un dato (il riferimento al dato va nella query string)
Quindi cosa fa la libreria?
semplice, si occupa di estrarre i dati (metodo, uri, lista di chiavi->valore e gli eventuali dati) dalla richiesta che vi passa il vostro client. E non solo; lo fa SENZA dover tenere in memoria TUTTA la richiesta, una cosa che invece vedo fare spesso e che porta inevitabilmente ad esaurire la RAM con catastrofici effetti. In effetti questa libreria usa solo lo spazio per i dati, il carattere attilamente letto e pochi byte per le variabili di gestione del tutto.
Cosa sono query string e corpo dati?
Prima di tutto non confondiamo query string con le query SQL che sono ben altra cosa, anche se spesso si incontrano 
esaminiamo una GET "pulita"
GET /index.html?user=asd HTTP/1.1
Host: www.example.com
GET è il metodo
/index.html è la URI, ovvero il file richiesto
user=asd è la query string, che ci dice che la variabile user è asd, puoi aggiungere altre variabili usando &
HTTP/1.1 è il PROTOCOLLO utilizzato, con arduino si implementa l'HTTP/1.0
Host: www.example.com è un header, di solito sono moltidi più ed a noi danno solo fastidio
la delete funziona allo stesso modo.
Se guardate molti siti, anche questo, sono piene di questi dati. (per esempio, la sezione software è la "board" 84.0, cambiando questo numerino vedete un pò dove finite!)
Ovviamente avrete anche visto quei siti cheriempiono la barran di numeri strani e arcani, il che è un pò brutto da vedere, ma potrebbe anche contenere dati sensibili; ecco che entrano in gioco POST e PUT con illoro corpo dati
esaminiamo ora una POST "pulita"
POST /index.html?user=asd HTTP/1.1
Host: www.example.com
dato1=una lunga sfilza di dati
notare lo spazio tra la fine degli header e l'inizio del corpo dati
il corpo dati non sarà visibile nella barra degli indirizzi (che però mostrerà come al solito l'uri completo di query string), in oltre il corpo dati NON ha alcunelimitazioni che ha l'URI, permettendo di usalro per inviare dati anche binari (non leggibili) senza problemi di codifica.
la PUT funziona allo stesso modo.
esempio di una GET vera:
GET / HTTP/1.1[CRLF]
Host: www.google.it[CRLF]
Connection: close[CRLF]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0[CRLF]
Accept-Encoding: gzip[CRLF]
Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7[CRLF]
Cache-Control: no-cache[CRLF]
Accept-Language: de,en;q=0.7,en-us;q=0.3[CRLF]
Referer: http://web-sniffer.net/[CRLF]
[CRLF]
[CRLF] equivale ad \n+\r, ovvero un invio
esempio di una POST vera:
POST / HTTP/1.1[CRLF]
Host: www.google.it[CRLF]
Connection: close[CRLF]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0[CRLF]
Accept-Encoding: gzip[CRLF]
Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7[CRLF]
Cache-Control: no-cache[CRLF]
Accept-Language: de,en;q=0.7,en-us;q=0.3[CRLF]
Referer: http://web-sniffer.net/[CRLF]
Content-type: application/x-www-form-urlencoded[CRLF]
Content-length: 12[CRLF]
[CRLF]
dati di test[CRLF]
[CRLF]
notare che esiste un header che ci dice quanti byte seguiranno, Content-length: 12, ho deciso di ignorarlo per semplicità
Rest.zip (3.47 KB)
