RFC 2616 include questo:
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
E poi quasi tutto il resto del documento è definito in termini di quelle entità (OCTET
, CHAR
, ecc.). Quindi è possibile esaminare la RFC per scoprire quali parti di una richiesta/risposta HTTP possono includere OCTET
s; tutte le altre parti devono essere ASCII. (Lo farei io stesso, ma ci vorrebbe molto tempo)
Per la riga di richiesta in particolare, il nome del metodo e la versione HTTP saranno solo caratteri ASCII, ma è possibile che l'URL stesso possa includere caratteri non ASCII. Ma se si guarda a RFC 2396, lo dice.
Un URI è una sequenza di caratteri da una serie molto limitata, vale a dire le lettere dell'alfabeto base latina, cifre e alcuni caratteri speciali.
Che presumo significa che sarà composto anche da caratteri ASCII.
fonte
2009-05-03 22:25:51
So che dovremmo ** aspettarci ** una frase di ragionamento, ma vuoi dire che è un ** tranne ** - anche lo ione? ;-) – Lucius