Re: JSON headers

On 12 July 2016 at 00:10, Willy Tarreau <w@1wt.eu> wrote:

> On Mon, Jul 11, 2016 at 11:58:03PM -0400, Yanick Rochon wrote:
>
> But precisely my point is to declare that all JSON headers are lists (or
> arrays apparently in JSON). Thus you just send array *elements* and the
> recipient appends them to the array. So you don't have the object above,
> you just have { "Accept": [ "..." ] }. This removes the possibility of
> duplicate keys and keeps the ability to have multiple values for a header.
> And it also allows to stop at the first value when you expect to use only
> one value for a header that you don't intend to check for uniqueness.
>
>
As Carsten mentioned, the problem is not the possibilities as you describe,
as I think JSON would elliminate a few problems that arises with the actual
implementation, but the issue is that people will not honor it. Meaning
that, JSON allows non-array values, so you cannot expect people to strictly
observe a rule (HTTP header having array values) and not another (JSON
values may be of other types). My question is more in the nature of "if a
sender sends duplicated keys in the header, and/or some of them are not
array values, what then?" As others have stated, the JSON specs is
undefined on this (i.e. overwriting previous ones, ignoring subsequent
duplicated keys, or rejecting the object with an error), and most
implementations end up overwriting as a convention. However this would lead
into problems where hijackers could simply insert their headers before the
closing curly brace, thus overriding any previous, original header.

You can't use an undefined behavior, make it a convention and expect people
to honor it; it has to be defined.