On 2011-10-29 04:36, =JeffH wrote:
>> Strict-Transport-Security = "Strict-Transport-Security" ":"
>> directive *( ";" [ directive ] )
>>
>> STS directives:
>>
>> directive = max-age | includeSubDomains | STS-d-ext
>>
>> max-age = "max-age" "=" delta-seconds
>
> What happens with
>
> max-age="1"
>
> ?
>
> Do you expect all recipients to reject this? Depending on the parsing
> API they use they might not even know that the value was quoted on
the wire.
Offhand, I'm not super sure, but after thinking about it while
researching/writing the below, I'm thinking "yes", max-age="1" is
invalid according to the ABNF and we should do whatever we do in error
cases (which is a separate open question). But implementors' parsing API
and its problems are out-of-scope for a spec such as this.
They are out-of-scope in that we don't specify them. But we still should
consider what's likely to be implemented, and the cost of not being able
to re-use a generic parser.
This obviously isn't the first HTTP response header field with such a
syntax and thus these potential issues (this one with a delta-seconds
value, and the issue you note below wrt "includeSubDomains"), yes?
Indeed. It's just I've been paying more attention to these kinds of
issues recently :-)
> > includeSubDomains = "includeSubDomains"
>
> There's a tiny risk that some implementations will handle value-less
> parameters the same way as parameters with empty values, such as
>
> includeSubDomains=
>
> or
>
> includeSubDomains=""
>
> but maybe I'm over-engineering here.
Yes, I'm wondering if this might be over-engineering -- I note that in
RFC 6266 you didn't distinguish/address this sort of case for "inline"
or "attachment" -- are you feeling now that you should have, and thus we
ought to do so going forward?
...
That case is a bit different as this is a stand-alone token, and there
do not seem to be any header fields that are similar to C-D but allow a
quoted-string in the first position.
Also see <http://greenbytes.de/tech/tc2231/#inlonlyquoted> -- some
recipients reject it, some don't. This is not a big issue per se, unless
those you reject it are forced to follow suite because senders start to
rely on it.
...
Best regards, Julian
_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
