- From: Simon Yarde <simonyarde@me.com>
- Date: Mon, 03 Feb 2014 13:46:17 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: ietf-http-wg@w3.org
> I think I would be pragmatic and just parse everything that looks like a parameter into a name/value map (and just trust that there'll be no "q" parameter ever). Yep — at the moment I do this and extract a "q" value as I go, resulting in a list of tuple values containing a weight and a transfer-coding. -- > type WeightedTransferCoding .. = (Weight, TransferCoding .. ) which benefits for being very easy to sort. But as I say, I ended up with a parser architecture/implementation that didn't *look* like the ABNFs and I had to introduce this concept of 'weighted-transfer-coding' :) Hope this may be of some help. Simon Yarde On 3 Feb 2014, at 13:36, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2014-02-03 14:26, Simon Yarde wrote: >> Thanks Julian — prompted by this, >> >>>> (c) that coding extension has a "q" parameter, >> >> >> I can see a way through for a sensible parser architecture; in that rather than trying to uniformly parse parameters, it becomes better to have specific transfer-coding parsers that only recognise registered/known attributes and skip/exclude all other parameters — from a functional-language perspective, it is preferable to have a data-type with a fixed number of parameters rather than an arbitrary-length mapping that *may* contain junk attributes. > > I think I would be pragmatic and just parse everything that looks like a parameter into a name/value map (and just trust that there'll be no "q" parameter ever). > >>> I agree that the ABNF is not optimal here, but it seems it is extremely unlikely that we'll ever see this happening. >> >> >> I've no wish to nit-pick for the sake of it and I agree it's unlikely, but someone still has to write parsers, and I was aiming to relay my own experience, in that there was still an element of 'divining' that had not improved on RFC2616. > > Understood. > >> Has this been addressed in HTTP/2.0? My apologies, but I've only had time to take an active interest in the HTTP/1.1 project since it happened to interface with my current project. >> ... > > HTTP/2.0 only defines a new message format; so what HTTP/1.1 says still applies. > > Best regards, Julian > >
Received on Monday, 3 February 2014 13:46:51 UTC