Re: JSON headers

> On Jul 10, 2016, at 3:10 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> 
> --------
> In message <94e4a5c2-3465-fef3-6221-d9f4fcccb5fa@gmx.de>, Julian Reschke writes
> :
> 
>> But right now the spec *is* written to use the list construct, and I 
>> believe that's a good thing, as it's IMHO better to consider multiple 
>> instances as legal, and require the definition of the header field to 
>> deal with it.
> 
> I think it is a bad thing.
> 
> It prevents streaming processing of headers, since you never know
> when you have the full picture for a particular header, until you've
> received them all and seen that there are no more instances.

Which is the nature of header fields in general, since we don't know if
a spoofing attempt is being made until we read all of the headers,
including the ones not defined as a list.  In any case, we can certainly
process them as a stream as long as we remember what has already been
processed so that an appropriate action can be taken for duplicates.

> It means also means that either you have to rewrite the headers, or
> all your code needs to do the brute-force collection scan and handle
> an array of headers for further processing.  Both of which is wasteful
> in terms of CPU and memory.

Umm, no; we can just use a bit to indicate that, or a pointer for speed.

> I see no advantages that come even close to compensating for those
> disadvantages, but if I have overlooked something, please enlighten me...

The reason duplicate header fields exist is because email wanted them for
stuff like Received being appended to header blocks, so the RFC822 syntax
enables them and recipients need to deal with that regardless of semantics.
The semantics we defined for HTTP/1 allow for new field values to be
processed and forwarded by a recipient without knowing its definition.
This is used in practice today by high-speed message forwarding with
zero-copy constraints to append certain fields at the end of each
header block.

It is theoretically possible to do the same thing within a special encoding
of a header field value, but then every recipient MUST implement that special
encoding in that special way prior to any deployed instances of that protocol,
which cannot happen for HTTP/1.x.  No, changing the minor version is not sufficient,
since the fields are required to be processable regardless of field definition
by existing intermediaries, which means duplicates will mess up the field in
unexpected ways unless the value encoding assumes a list syntax will happen
whether you like it or not.

In any case, this discussion has nothing to do with Julian's proposal, which
is to define a common field syntax for HTTP/1.x field values that for some
insane reason want to use JSON for field processing.  Maybe that's just to add
UTF-8 characters, or for embedding field name-value pairs within other fields
(as was the case for logic bags, ages ago, or Key today), but it deserves to
be discussed in terms of what the draft defines and not hijacked into a
general discussion of HTTP/3.

....Roy

Received on Thursday, 14 July 2016 19:30:08 UTC