Subject: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux)

From: =JeffH <[email-masked]>
Date: Fri, 13 Jan 2012 16:24:06 -0800

In terms of this question of whether the STS header field directive ABNF should 
be..

1)  directive         = token [ "=" ( token | quoted-string ) ]

..or..

2)  directive         = token [ "=" token ]

..I can see both sides of the argument.

However, I've been thinking about it and grepping thru specs as well as firefox 
and chrome code, which has led me to think that from an overall (specification) 
consistency perspective, I'm leaning towards spec'g it with quoted-string in 
the ABNF (ie, as (1)). And has been pointed out in the discussion, it is sort 
of a moot point because the STS header field does not at this time make use of 
the quoted-string production, nor do we have on the table any extension 
directives that would do so.

In going through the FF and Chrome code, I note that both of their STS header 
field parsing methods appear to be special-case and AFAICT don't make use of 
other, more general HTTP header field parsing routines that are available in 
both implementations, and that are used to parse other HTTP response header 
fields. These latter more general HTTP header field parsing routines appear to 
be used for processing various of the other HTTP response and request header 
fields (and they appear to handle quoted-string). But it isn't clear why they 
aren't used for STS. It also isn't clear how uniformly these parsing routines 
are used for the panoply of HTTP header fields -- some other header fields 
appear to be special-cased as well (tho my c++ foo is wanting and the code is 
vast..). So yeah, it does seem messy.

=JeffH

---

From: Julian Reschke <[email-masked]>
Date: Sat, 14 Jan 2012 13:20:24 +0100

On 2012-01-14 01:24, =JeffH wrote:
>
> In terms of this question of whether the STS header field directive ABNF
> should be..
>
> However, I've been thinking about it and grepping thru specs as well as
> firefox and chrome code, which has led me to think that from an overall
> (specification) consistency perspective, I'm leaning towards spec'g it
> with quoted-string in the ABNF (ie, as (1)). And has been pointed out in

+1

> the discussion, it is sort of a moot point because the STS header field
> does not at this time make use of the quoted-string production, nor do
> we have on the table any extension directives that would do so.

It's not a moot point at all. If you don't spec it now, extensions will 
not ever be able to use quoted-string, because recipients parsing over 
those extensions will trip over them.

> In going through the FF and Chrome code, I note that both of their STS
> header field parsing methods appear to be special-case and AFAICT don't
> make use of other, more general HTTP header field parsing routines that
> are available in both implementations, and that are used to parse other
> HTTP response header fields. These latter more general HTTP header field
> parsing routines appear to be used for processing various of the other
> HTTP response and request header fields (and they appear to handle
> quoted-string). But it isn't clear why they aren't used for STS. It also
> isn't clear how uniformly these parsing routines are used for the
> panoply of HTTP header fields -- some other header fields appear to be
> special-cased as well (tho my c++ foo is wanting and the code is

It's true what right now there isn't a lot of re-use of header field 
parsers. This is likely because of historic reasons; different header 
fields have different parsing quirks.

But of course that's not an excuse to add unneeded special cases in the 
future.

Example: just a few weeks ago we discussed the "Prefer" header field in 
the HTTPbis WG, and we have been able to make it parse exactly like 
"Expect" (after fixing "Expect" as well, see 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/327>).

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Sun, 15 Jan 2012 13:53:37 -0800

On Fri, Jan 13, 2012 at 4:24 PM, =JeffH <[email-masked]> wrote:
> (specification) consistency perspective, I'm leaning towards spec'g it with
> quoted-string in the ABNF (ie, as (1)). And has been pointed out in the
> discussion, it is sort of a moot point because the STS header field does not
> at this time make use of the quoted-string production, nor do we have on the
> table any extension directives that would do so.
>
> header field parsing methods appear to be special-case and AFAICT don't make
> use of other, more general HTTP header field parsing routines that are
> available in both implementations, and that are used to parse other HTTP
> response header fields. These latter more general HTTP header field parsing
> routines appear to be used for processing various of the other HTTP response
> and request header fields (and they appear to handle quoted-string). But it
> isn't clear why they aren't used for STS. It also isn't clear how uniformly
> these parsing routines are used for the panoply of HTTP header fields --
> some other header fields appear to be special-cased as well (tho my c++ foo
> is wanting and the code is vast..). So yeah, it does seem messy.

It's definitely messy.

I don't think it matters much what we write in this document.  Even if
we spec quoted-string, I doubt many folks will implement it.  However,
we can deal with that problem when it comes time to add extension
values that actually used quoted-string.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Sun, 15 Jan 2012 23:11:02 +0100

On 2012-01-15 22:53, Adam Barth wrote:
> ...
> ...

Apologies for the direct question: just 14 days ago you stated that you 
did not implement q-s in Chrome, and that you don't intend to:

AB> Chrome does not (and will not) implement quoted-string for the STS
AB> header for the reasons I've explained previously.  You're welcome to
AB> file bugs, but I'm just going to close them WONTFIX.

That's somewhat different from what you say now.

Is "the extensions do not exist yet" the excuse for not implementing 
what the spec says? Will you be around for fixing Chrome when the first 
bug reports because of broken extensions come in?

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Sun, 15 Jan 2012 14:24:50 -0800

On Sun, Jan 15, 2012 at 2:11 PM, Julian Reschke <[email-masked]> wrote:
> Apologies for the direct question: just 14 days ago you stated that you did
> not implement q-s in Chrome, and that you don't intend to:
>
> Is "the extensions do not exist yet" the excuse for not implementing what
> the spec says? Will you be around for fixing Chrome when the first bug
> reports because of broken extensions come in?

I don't plan to implement quoted-string in Chrome.  I'm saying that
I'm not going to object to writing quoted-string into the spec.  I
still think it's a bad idea, but I'm dropping my objection to it.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Sun, 15 Jan 2012 23:27:59 +0100

On 2012-01-15 23:24, Adam Barth wrote:
> On Sun, Jan 15, 2012 at 2:11 PM, Julian Reschke<[email-masked]>  wrote:

So when the bug reports come in, *somebody else* is going to fix Chrome?

I really want to know.

---

From: Adam Barth <[email-masked]>
Date: Sun, 15 Jan 2012 14:55:06 -0800

On Sun, Jan 15, 2012 at 2:27 PM, Julian Reschke <[email-masked]> wrote:
>>> did

I doubt it will be high on anyone's priority list.  If you'd like to
implement it, you're welcome to submit a patch.  (Of course, I can't
promise that the patch will be accepted.)

Adam

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jan 2012 00:03:24 +0100

On 2012-01-15 23:55, Adam Barth wrote:
> On Sun, Jan 15, 2012 at 2:27 PM, Julian Reschke<[email-masked]>  wrote:

14 days ago you said:

 > Chrome does not (and will not) implement quoted-string for the STS
 > header for the reasons I've explained previously.  You're welcome to
 > file bugs, but I'm just going to close them WONTFIX.

Has this changed? Will patches be closed as WONTFIX no matter how good 
they are?

It *really* would be helpful if you would clearly state your position. 
And also clarify on whose behalf you are speaking here.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Sun, 15 Jan 2012 15:12:31 -0800

>>>>>> values that actually used quoted-string.
\>>>>>
>>>>> what
> Has this changed? Will patches be closed as WONTFIX no matter how good they
> are?

I'll state my opinion about the patch, which hasn't changed.  However,
it's an open source project.  You're welcome to submit whatever
patches you like.  They'll get reviewed and discussed, just like any
other patches.

> It *really* would be helpful if you would clearly state your position. And
> also clarify on whose behalf you are speaking here.

Am I not being clear?  I'm not going to implemented quoted-string, and
I doubt that many other folks will either.  I'm no longer objecting to
including quoted-string in the spec (although I believe including it
is the wrong decision).

As is customary at the IETF, I speak for myself.

Adam