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

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 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.

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.

Simon Yarde


On 3 Feb 2014, at 13:05, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2014-02-03 13:44, Simon Yarde wrote:
>> 
>>> Why exactly is the ABNF a problem?
>> 
>> 
>> Because the rule for transfer-parameter is in conflict with t-ranking when the transfer-coding rule is imported to t-codings (copied below).
>> 
>> Is the protocol trying to say that the transfer-extension parser must halt if is sees anything matching a "q" attribute?  I.e.
>> 
>> -- > attribute          = token   ; except "q"
>> 
>> 
>> -- > transfer-coding    = "chunked" ; Section 4.1
>> -- >                    / "compress" ; Section 4.2.1
>> -- >                    / "deflate" ; Section 4.2.2
>> -- >                    / "gzip" ; Section 4.2.3
>> -- >                    / transfer-extension
>> -- > transfer-extension = token *( OWS ";" OWS transfer-parameter )
>> -- >
>> *- > transfer-parameter = attribute BWS "=" BWS value
>> -- > attribute          = token
>> -- > value              = token / quoted-string
>> 
>> -- > TE        = #t-codings
>> *- > t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
>> *- > t-ranking = OWS ";" OWS "q=" rank
>> -- > rank      = ( "0" [ "." 0*3DIGIT ] )
>> -- >           / ( "1" [ "." 0*3("0") ] )
>> 
>> 
>> As a side-note on tolerance, I was also aiming to highlight that client libs are likely to construct dictionaries with arbitrary ordering of parameters (in languages where dict ordering is not guaranteed), and thus the t-coding value will likely occur anywhere in a list of parameter-like values — but yes, I do note that the rule states that t-ranking *follows* a transfer-coding (and any attendant transfer-parameters), and it would be an error to include any more text after a t-ranking.
>> ...
> 
> Yes.
> 
> In practice, all of this only becomes relevant if people (a) use qvalues on TE, (b) use a coding extension that has parameters, (c) that coding extension has a "q" parameter, and (d) that parameter does not appear last.
> 
> I agree that the ABNF is not optimal here, but it seems it is extremely unlikely that we'll ever see this happening.
> 
> Best regards, Julian

Received on Monday, 3 February 2014 13:27:00 UTC