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

On Feb 3, 2014, at 2:54 AM, 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.

That isn't misleading.  The ABNF requires that the t-ranking (weight)
be the last parameter per transfer-coding when it is used in TE.

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

Or the ordering algorithm could extract them after parsing, or it
could just ignore the weights.  Those are implementation-specific
concerns.

In practice, none of this matters, since nobody sends parameters
within TE, and if they ever do they won't be so foolish as to use
'q' as a parameter name.

....Roy

Received on Wednesday, 5 February 2014 09:11:25 UTC