Re: JSON headers

On 10 July 2016 at 06:10, 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.
>
> 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.
>
> I see no advantages that come even close to compensating for those
> disadvantages, but if I have overlooked something, please enlighten me...
>
>
I agree. Normally, multiple instances are legal in JSON and the latest will
simply override the previous one, but in the case of headers, it is not
good indeed and may produce problem when a repeating header comes after a
few preliminary configurations have been set and will force retrieving the
entire header object instead of the actual implementation (i.e. it would be
a regression, not an improvement). Since streaming headers (feasable in
JSON) is preferrable, duplicated keys in the JSON header should either be
ignored or rejected with an error. It is the responsibility of the sender
to properly format it's header before sending, not the server to untangle a
messy one. In my opinion, repeating headers should be put in an array,
period.