W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

RE: #307 (untangle Cache-Control ABNF)

From: Manger, James H <James.H.Manger@team.telstra.com>
Date: Thu, 14 Jun 2012 14:29:34 +1000
To: Mark Nottingham <mnot@mnot.net>, Julian Reschke <julian.reschke@gmx.de>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F55FCCEC@WSMSG3153V.srv.dir.telstra.com>
>>> I see. I understand what you're trying to do, but I think it's too
>>> easy to misread it as "all new directives must be defined to allow both
>>> forms", which is both unnecessary and not realistic.

>> No, that's actually the *intent*. I believe it's both necessary *and*
>> realistic.

> So, I didn't see what you're trying to do. However, above you say it's
> not specific to extensions, but as you say later, that's the effect
> (and intent).
> I think it's going too far; in similar situations we haven't laid down
> such draconian rules.

My interpretation of Julian's crusade, using max-age as an example:

1. The syntax for a generic parameter is: token ["=" (token / quoted-string)].

2. A generic parser will accept max-age=5 and max-age="5" and max-age="\5", and simply make a one-character string available to the next stage (eg make it available in a dictionary).

3. handleMaxAge() code will use the 1-char string, checking it matches delta-seconds. handleMaxAge() doesn't know, nor care, which of the 3 forms in step 2 was received.

4. A developer wants to set max-age. He learns it is a decimal number in seconds. He doesn't closely read the spec. He sees some other xxx="yyy" parameters. He tries max-age="5". It works. He deploys his code.

5. Months later, after the developer's code has been working fine in systems X & Y, it fails with system Z. Z wasn't using a generic parser. Z enforced the max-age=token restriction.
=> Interop failure

Syntactically there is no need to allow max-age=quoted-string, but if some systems except that then other systems will start relying on it, then interop will fail with systems that don't allow it.

If, like system Z, you don't use a generic parser then Julian's rule is annoying. It means you have to support quoted-string for a field that shouldn't need it just in case a developer is sloppy. It doesn't seem fair. You have to do extra work up-front (supporting quoted-string, probably by switching to a generic parser) to save possible interop pain later.

Julian's rule encourages use of generic parsers (a good thing); and ensuring all developers diligently read our specs is not realistic. So (grudgingly) it is probably the best approach (or at least it would be if it supported any Unicode string value).

James Manger

Received on Thursday, 14 June 2012 04:30:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:03:37 UTC