- From: Simon Yarde <simonyarde@me.com>
- Date: Mon, 03 Feb 2014 11:41:53 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: ietf-http-wg@w3.org
Thanks Julian — I noticed this in my docs and felt it would be worth throwing out there in view of the push to wrap-up soon. > 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. This seems eminently sensible and unlikely to disrupt the review findings, since it simply replicates an accepted approach to add clarity. That said, it still isn't possible to directly implement parsers for media-type and transfer-coding ABNF rules, and by association the TE and Accept rules. Simon Yarde On 3 Feb 2014, at 11:12, Julian Reschke <julian.reschke@gmx.de> wrote: > 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:42:26 UTC