Re: Precision of numbers using JSON Header Field Values

Hi Poul-Henning,

On Sun, Jul 17, 2016 at 07:14:22AM +0000, Poul-Henning Kamp wrote:
> --------
> In message <20160717054057.GD23841@1wt.eu>, Willy Tarreau writes:
> 
> >It [JSON] might appear as a bad solution but the least bad of all other ones.
> 
> The first half I can certainly agree with.
> 
> But the second half is far from obvious to me, and I nowhere have I
> seen anything like a survey or analysis saying so.
> 
> For me it is a question of consequences.
> 
> I don't want us to be stuck with mandatory JSON if/when we attempt
> a HTTP/3 protocol, unless we already now address and somehow neuter/
> manage the worst of the trouble JSON comes with[1].
> 
> If we limit JSON to only end-to-end headers, H3 will only need to
> be able to move them, and never have to parse them.
> 
> But if we allow JSON to creep into 'transport headers', as Julians
> "Accept:" example seems to both imply and promise, we will be stuck
> with JSON *forever*.
> 
> Do you feel like parsing JSON in a 100Gbit/sec load-balancer ?

Well, as I mentionned at the workshop in last July, I don't like JSON
but I have no technical argument against it and just for this I want to
give it some consideration without any form of bias. This is what is
being done in this thread and in Julian's initial draft. If at the end
it happens it's really not suited, then we'll have a lot of elements
to know why it is not and what needs to be avoided in the solution we
design as a replacement. For now, I'm seeing some difficulties with
numbers representation and with the ordering of duplicate fields. It is
possible that addressing them will come with a high cost or that some
smart people will propose very simple solutions, I don't know.

What is sure is that I don't feel like manually dealing with the tricks
of this thread on a 100Gbps LB, but I'm much more scared by the idea that
these tricks will simply be overlooked at many other places and result
in security vulnerabilities or at least poor interoperability. I'd
strongly prefer an efficient binary encoding that would pass well over
H2 / H3 whatever, but still we know that H1 will exist for many years,
that applications deal with headers as text and we'll need a text-based
representation at some points along the chain. Maybe we'll end up with
something "looking like" JSON for text versions, will be easy to serialize
to efficient and safe binary for more recent protocols etc... I don't know
but the discussion should help us spot the unfixable problems if any. And
given the number of degrees of freedom of the current HTTP headers grammar,
I'm inclined to think that only two reported issues for now is a low score
to attack this proposal.

Regards,
Willy

Received on Monday, 18 July 2016 12:15:14 UTC