On 2011-09-28 01:16, =JeffH wrote:
thx for the comments Julian.
> On 2011-09-14 23:08, =JeffH wrote:
>> > a few questions about the header field syntax:
>> >
>> > Strict-Transport-Security =
>> > "Strict-Transport-Security" ":" OWS STS-v OWS
>> >
>> > So the header field is *not* using the RFC2616 list syntax. So you
>> can have
>> >
>> > Strict-Transport-Security: a; b
>> >
>> > but *not*
>> >
>> > Strict-Transport-Security: a
>> > Strict-Transport-Security: b
>> >
>> > because that would be equivalent to
>> >
>> > Strict-Transport-Security: a, b
>> >
>> > (is this intentional?)
>>
>> well, it was not necessarily intentional as far as I recall. We either
>> managed to overlook, or regarded as inappropriate for this header, the
>> RFC2616 list syntax (i.e., the "#rule"), that defines such implicit
>> comma-separated lists.
>> Also, we'd noted that quite a number of header field definitions used
>> semi-colons as a delimiter, but perhaps hadn't noted that those overall
>> productions often are embedded within such comma-separated lists.
>
> Yes, that's the list-of-parametrized-things format.
>
>> However, in thinking about it a little bit, for this particular header
>> field, as it's presently defined, it doesn't seem appropriate to
have it
>> explicitly be comma-separated repeatable (aka #rule), because only one
>> instance of "S-T-S: max-age=n" is effective in terms of established the
>> cached Known HSTS Host in the UA.
>
> In that case, as this is security related, you may want to talk about
> what recipients are to do when (a) they *do* get multiple instances,
that's already done in -websec-strict-transport-sec-02 in S 7.1.
Indeed:
If a UA receives more than one Strict-Transport-Security
header field in a HTTP response message over secure transport,
then the UA SHOULD process only the first such header field.
I think it would be cleaner to consider the message broken in this case.
> and
> (b) when an intermediate folds multiple headers using the comma syntax.
ah, so an intermediate can/might do that to multiple occurrences of any
header field in a message ?
Yes.
>> > Also in
>> >
>> > ; value
>> > STS-v = STS-d
>> > / STS-d *( OWS ";" OWS STS-d OWS )
>> >
>> > ; STS directive
>> > STS-d = STS-d-cur / STS-d-ext
>> >
>> > ; defined STS directives
>> > STS-d-cur = maxAge / [ includeSubDomains ]
>> >
>> > having includeSubDomains optional is a bit weird.
>> >
>> > This means that the empty string would be a valid STS-d-cur, thus an
>> > empty header field is allowed...
>>
>> Ah, thanks, yes -- i was unsure of how to make includeSubDomains
>> optional while max-age is required, and that hack didn't work.
>>
>> I've now re-worked it as below -- how's that look?
>>
>> thanks again,
>>
>> =JeffH
>>
>>
>> Strict-Transport-Security =
>> "Strict-Transport-Security" ":" OWS STS-v OWS
>>
>> ; STS header field value; must have a max-age:
>>
>> STS-v = max-age
>> / max-age *( OWS ";" OWS STS-d OWS )
>
> ...which makes putting max-age first required.
>
>> ; additional STS directives:
>>
>> STS-d = STS-d-cur / STS-d-ext
>>
>> ; currently defined STS directives,
>> ; delta-seconds is 1*DIGIT and is from [RFC2616]:
>>
>> max-age = "max-age" OWS "=" OWS delta-seconds [ OWS v-ext ]
>>
>> STS-d-cur = includeSubDomains
>>
>> includeSubDomains = "includeSubDomains" [ OWS v-ext ]
>>
>>
>> ; extension points
>> STS-d-ext = name ; STS extension directive
>>
>> v-ext = value ; STS extension value
>>
>> name = token
>>
>> value = OWS / %x21-3A / %x3C-7E ; i.e. optional white space, or
>> ; [ ! .. : ] [ < .. ~ ] any visible chars other than ";"
>>
>> token = 1*tchar
>>
>> tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
>> / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
>> / DIGIT / ALPHA
>> ; visible (printing) characters, except visible
>> ; separators.
>> ; DIGIT, ALPHA, separators are from [RFC2616]
>>
>> ; Basic rules:
>>
>> OWS = *( [ CRLF ] WSP )
>> ; Optional White Space
>>
>> WSP = SP / HTAB
>>
>> CRLF = CR LF
>>
>> ; CR, LF, SP, HTAB are from [RFC2616]
>>
>>
>> ---
>> end
>
> I think it would be simpler not to try to express this in the ABNF.
what do you mean by "this" ?
Essentially constraints on what directives need to be there (as opposed
to their syntax).
> Just use the ABNF to state the core syntax (that a parser will need to
> understand), and then put additional requirements about what directives
> must be there in prose (we're doing the same in HTTPbis, but aren't done
> yet... :-).
do you have a particular example in mind?
HTTPbis, for instance, doesn't enumerate header field names in the ABNF
anymore.
I'm guessing that the Expect header might be a good example, from
-httpbis-p2-semantics-16, yes?
Not really, it still has the directive "100-continue" spelled out in the
ABNF.
Best regards, Julian
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
