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

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