On 2011-10-07 01:23, =JeffH wrote:
...
Trying to summarize my concerns and proposals...
(1) RFC2616-or-HTTPbis
In a perfect world I could give you an exact time-of-arrival for
HTTPbis. But the world is not perfect; and progress on HTTPbis mainly
depends on the availability of the editors, and, more importantly,
people showing up on the HTTPbis mailing list to help in closing issues
and reviewing the existing text. So help *is* appreciated. ->
<http://trac.tools.ietf.org/wg/httpbis/trac/wiki>
(2) Multiple header instances
Header fields can occur multiple times, even when they were intended not
to. Examples: Location, Content-Length. When this happens, we usually
see interop problems because some consumers pick the first, some pick
the second, and some combine them using a comma, as described in HTTP spec.
This can be dangerous when the repetition makes the message format
ambiguous (Content-Length, for instance). It also means that it allows
smuggling, relying on checkers/intermediaries only seeing one of the
headers.
Note that Chrome and FF have become very strict in checking for this for
C-L, and FF does even more checks (syntax of C-L, also checks for
Location and Content-Disposition).
So *if* STS doesn't allow multiple header fields (which would require
switching to a comma-separated syntax), the spec should be crystal clear
what to do when multiple instances are encountered; in many cases the
default should be "ignore the header field" or even "consider the
message to be broken". Not sure what's best here.
Also note that somebody else may be combining multiple fields into a
single one, and the recipient will see those concatenated with commas as
separators. Optimally the format is robust enough to detect things like
that.
(3) ABNF organization
Any header field that is extensible needs to define the syntax for the
extension point, so existing code can parse them. Don't make extensions
different from the builtins with respect to syntax. It just makes the
parser more complicated.
So just define a single ABNF for STS directives in ABNF.
For instance, using RFC 2616 ABNF and list syntax:
Strict-Transport-Security =
"Strict-Transport-Security" ":" 1#directive
...or when sticking to semicolon:
Strict-Transport-Security =
"Strict-Transport-Security" ":" directive *( ";" directive )
Then
directive = token( "=" ( token / quoted-string ) )
In prose, add additional constrains, such as "MUST contain FOOBAR
directive exactly once".
Finally, for each builtin directive state the individual syntax of the
param *value*, and do not make the ABNF vary based on the directive.
Hope this helps.
Also worth reading:
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#considerations.for.creating.header.fields>
Best regards, Julian
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
