Re: Call for Adoption: draft-reschke-http-jfv

On 2016-03-11 07:41, Willy Tarreau wrote:
> On Fri, Mar 11, 2016 at 05:02:26PM +1100, Mark Nottingham wrote:
>> <https://tools.ietf.org/html/draft-reschke-http-jfv>
> (...)
>> Julian has confirmed that he is willing to continue editing, and our AD is
>> aware of this work. The only thing I'll add is that people shouldn't get too
>> hung up on the exact syntax currently proposed; based on our discussions, it
>> might change significantly.
>>
>> There's already been support for it demonstrated at the meetings we've talked
>> about it. Any additional thoughts?
>
> I'm personally not fond of JSON, I remember that the first time Julian
> talked about this, I had a grimace. But short after that I had to admit

(Believe me, I'm not a JSON fan boy, either. Spending a lot of my time 
with XML and XSLT and enjoying it...)

> I couldn't find any solid technical argument against this choice. JSON has
> the merit of being relatively easy to encode and decode, to be flexible,
> and to add very low overhead on top of text-based communications (which is
> our case here).
>
> I remember that Kazuho showed it was possible to simplify the common case
> (single value) to end up with basically no change compared to the current
> format.

Yes, and I apologize not to have fully followed up on this...

> I think my real fear comes from the risk of seeing people start to serialize
> whatever they can imagine into header fields. We've already seen multi-kilobyte
> cookies in the wild, if headers become officially JSON-like, maybe some
> people will consider it normal to abuse them. On the other hand it's hard
> to declare some protocol limits that we won't regret later.

That is indeed a risk; is there anything we can do about it except warning?

> The other point to think about is to help recipients detect the presence
> of such encoding in unknown header fields. I guess that the current draft
> makes this relatively easy and that Kazuho's suggestion maintains this
> possibility.

That's a discussion I'd like to have later. For now this is just for new 
header fields where the recipient will know about the format. Simple 
things first...

> I'm seeing a risk of corruption along the path due to the use of the
> comma in JSON, because unaware intermediaries may consider this as a
> series of comma-delimited values and possibly fail to properly re-encode
> them (or modify some of them). But at this point that's a minor detail.

Interesting point. Have you seen this in practice?

> Overall I think this is very useful research work and I hope to see it
> make forward progress. The faster we can rely on such a document for
> new fields, the better. And it's important not to start to use parts of
> it until it's adopted, we definitely don't want to have multiple decoders
> depending on the fields that will have been invented before and the ones
> after the adoption!
>
> Just my two cents,
> Willy

Best regards, Julian

Received on Friday, 11 March 2016 07:13:02 UTC