RFC 2616 incluye lo siguiente:
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)>
Y entonces casi todo lo demás en el documento se define en términos de esas entidades (OCTET
, CHAR
, etc.). De modo que podría consultar el RFC para averiguar qué partes de una solicitud/respuesta HTTP pueden incluir OCTET
s; todas las demás partes deben ser ASCII. (Lo haría yo mismo, pero tomaría mucho tiempo)
Específicamente para la línea de solicitud, el nombre del método y la versión HTTP van a ser caracteres ASCII solamente, pero es posible que la URL misma pueda incluir caracteres no ASCII Pero si mira RFC 2396, dice eso.
Un URI es una secuencia de caracteres de un conjunto muy limitado, es decir, las letras del alfabeto latino básico, los dígitos y algunos caracteres especiales.
Lo que supongo significa que también constará de caracteres ASCII.
Sé que debemos ** esperar ** una frase de motivo, pero ¿quiere decir que es ** ** también? ;-) – Lucius