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

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.


# HTTP/2.0 Proposal / Sketch

I'm not sure if this has been dealt with, but I concluded in a note that HTTP/2.0 might want to consider some other way to deal with "weight" given that it is such an important aspect of content-negotiation and clashes badly with custom-parameters.

If something like the rule below could be achieved then it would be very easy to logically /extend/ any rules that may be used in a /weighted context/:


-- > weighted-transfer-coding = [ weight-value "~" ] transfer-coding

E.g.  1~custom-compress;foo=bar;q=no-clash, 0.9~gzip, 0.5~deflate


-- > weighted-media-type = [ weight "~" ] media-type

E.g.  1~text/plain;q=no-clash, 0.5~text/html;foo=bar



-- > weight-value = ( "0" [ "." 0*3DIGIT ] )
-- >              / ( "1" [ "." 0*3("0") ] )


Best Regards

Simon Yarde

Received on Monday, 3 February 2014 10:55:48 UTC