W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: TE / transfer-coding issue with qvalue and transfer-parameters HTTP/1.1, HTTP/2.0

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 03 Feb 2014 14:36:13 +0100
Message-ID: <52EF9B4D.90808@gmx.de>
To: Simon Yarde <simonyarde@me.com>
CC: ietf-http-wg@w3.org
On 2014-02-03 14:26, Simon Yarde wrote:
> Thanks Julian  prompted by this,
>
>>> (c) that coding extension has a "q" parameter,
>
>
> I can see a way through for a sensible parser architecture;  in that rather than trying to uniformly parse parameters, it becomes better to have specific transfer-coding parsers that only recognise registered/known attributes and skip/exclude all other parameters  from a functional-language perspective, it is preferable to have a data-type with a fixed number of parameters rather than an arbitrary-length mapping that *may* contain junk attributes.

I think I would be pragmatic and just parse everything that looks like a 
parameter into a name/value map (and just trust that there'll be no "q" 
parameter ever).

>> I agree that the ABNF is not optimal here, but it seems it is extremely unlikely that we'll ever see this happening.
>
>
> I've no wish to nit-pick for the sake of it and I agree it's unlikely, but someone still has to write parsers, and I was aiming to relay my own experience, in that there was still an element of 'divining' that had not improved on RFC2616.

Understood.

> Has this been addressed in HTTP/2.0? My apologies, but I've only had time to take an active interest in the HTTP/1.1 project since it happened to interface with my current project.
> ...

HTTP/2.0 only defines a new message format; so what HTTP/1.1 says still 
applies.

Best regards, Julian
Received on Monday, 3 February 2014 13:36:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC