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

On 2014-02-03 11:54, Simon Yarde wrote:
> Whilst implementing parsers for HTTP/1.1 I encountered issues affecting transfer-parameters in the context of the TE rule that may have broader implications to HTTP/2.0;  namely that weight-value (aka "q" value / param) cannot be distinguished from transfer-parameters.  More generally this issue affects any situation where a weight-value is combined with parameters.
>
> # HTTP/1.1 Proposal
>
> For HTTP/1.1 I think the issue can be dealt with using a MAY NOT rule — here's the relevant notes from my docs as they occurred to me at the time:
>
> -- /Note/ — there is an issue with the protocol whereby @weight@ (aka
> -- @qvalue@) elements cannot be distinguished from
> -- @transfer-parameters@.  Custom @transfer-extensions@ MUST NOT use an
> -- attribute of @q@ (case-insensitive) in the context of a
> -- @weighted-transfer-coding@, and should generally avoid such use to
> -- avoid conflicts.  The ABNF rule is probably misleading because
> -- the @weight@ element in reality may occur anywhere amongst other
> -- parameters-like-elements, although technically the protocol says it
> -- must follow any parameters;  nonetheless it cannot be distinguished
> -- from parameter-like-elements.
>
> I felt I needed to introduce a 'weighted-transfer-coding' parser since I could not cleanly implement transfer-coding for use within a TE parser — i.e. the transfer-coding rule/parser would already have consumed a "q" parameter as a transfer-parameter before the TE rule had a chance to operate.
>
> There were also some points that may be worth highlighting for tolerance in TE:
>
> -- Only a @transfer-extension@ value permits parameters.  Illegal
> -- parameters following any other @transfer-coding@ are skipped.
>
> -- If occurances of the @trailers@ element are found then the
> -- 'AcceptTrailers' value in the result will be 'True'.  Illegal
> -- parameters following a @trailers@ element will cause the parser to
> -- fail, on the basis that the message is probably garbled.
> --
> -- Occurances of @transfer-coding@ value @chunked@ are skipped as per
> -- protocol guidance.
> ...

A similar issue exists with "Accept:", where we already say:

"Note: Use of the "q" parameter name to separate media type parameters 
from Accept extension parameters is due to historical practice. Although 
this prevents any media type parameter named "q" from being used with a 
media range, such an event is believed to be unlikely given the lack of 
any "q" parameters in the IANA media type registry and the rare usage of 
any media type parameters in Accept. Future media types are discouraged 
from registering any parameter named "q"." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#rfc.section.5.3.2>

For TE and Accept-Encoding the simplest possible fix is to add that to 
the sections about considerations for new encodings. Note that 
registration of both transfer codings and content codings require "IETF 
Review", so that bar is relatively high anyway.

That being said: we are past WG LC, IETF LC, and IESG review, so I'm 
reluctant to make more changes at this point.

Best regards, Julian

.

Received on Monday, 3 February 2014 11:12:41 UTC