Re: PROPOSAL: i74: Encoding for non-ASCII headers

On Mar 28, 2008, at 7:09 PM, Jamie Lokier wrote:
> I see why your instincts go that way, but I think it's a mistake to
> assume "no problem".  Those sequences, when decoded differently by
> different applications, can hide a lot of nasty things.

Only if those applications are ridiculously broken already, such
as by parsing the message after transcoding the encoded characters.
We don't need to care if that ship sinks.

Please, unless folks have specific implementations that have not yet
been discussed, there is no need to respond to every message as if
the weight of opinions were measured in words.  Speculation doesn't
mean diddly when we are talking about an old protocol that already
has a thousand independent implementations.  A change like this one,
that actually impacts on-the-wire parsing of compliant messages,
should be proven in the field before it is even considered for
the spec.  So, while I don't anticipate any problems with even raw
UTF-8 being placed in TEXT areas, the fact of the matter is that
the specification cannot be called HTTP/1.1 unless there are at least
two clients and two servers implemented to make use of it and NO
known breakage with previously interoperable implementations.

I'd rather defer this issue until much later in the process,
namely after the generic message parsing algorithm has been
written properly so that it will be clear that no compliant
implementation needs to care about the field-content in general
beyond it being defined (and parsed) in terms of ASCII delimiters.
If that can be shown to be implemented and interoperable, then we
need only define the parsing of individual field *content* within
those field definitions (which may or may not be within 2616bis).

....Roy

Received on Saturday, 29 March 2008 04:54:57 UTC