https://issues.apache.org/bugzilla/show_bug.cgi?id=45406
--- Comment #6 from Will Rowe <[EMAIL PROTECTED]> 2008-07-16 07:58:51 PST ---
If we are to accept UTC-16, let's examine the bytestream of a GET request;
GET
\0h\0t\0t\0p\0:\0/\0/\0a\0.\0c\0o\0m\0?\0u\0t\0f\0001\0006\0p\0a\0r\0a\0m\0e\0t\0e\0r\0=\0\0%\0D\00007\0%\0000\0005
HTTP/1.1
*That* is utc-16 encoding.
It's clearly defined as OCTETs, and the 'GET' sp and sp "HTTP/n.n" are defined
in
ASCII.
I'm having a hard time coming to another conclusion, perhaps you can offer one?
Especially relevant are the definitions;
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
Further, consider the statement;
Characters other than those in the "reserved" and "unsafe" sets (see
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
which is nonsensical unless the ASCII definitions of reserved and unsafe
are taken literally.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
