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: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 5 Feb 2014 01:11:01 -0800
Cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
Message-Id: <F90BF433-408E-4CB5-A286-667A581B71B7@gbiv.com>
To: Simon Yarde <simonyarde@me.com>
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

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.

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

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