Re: #409: is parsing OBS-FOLD mandatory?

[Willy Tarreau <[e-mail]>]

Hi Mark,

On Wed, Dec 12, 2012 at 02:48:55PM +1100, Mark Nottingham wrote:
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/409>
> 
> """
> p1 2.5 Conformance and Error Handling says "...recipient MUST be able to parse any value that would match the ABNF rules..." yet 3.2.2 only make parsing obs-fold a SHOULD. Which is it?
> """
> 
> Roy made a proposed edit to remove the MUST NOT generate and change the SHOULD parse to a MUST parse.
>   <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2039>
> 
> However, this has the effect of un-deprecating line folding; IIRC we added
> those requirements because folding is not interoperable. 
> 
> My suggestion would be to change:
> 
> """
> If a received protocol element is processed, the recipient must be able to
> parse any value that would match the ABNF rules for that protocol element,
> excluding only those rules not applicable to the recipient's role.
> """
> 
> to:
> 
> """
> If a received protocol element is processed, the recipient MUST be able to
> parse any value that would match the ABNF rules for that protocol element,
> excluding only those rules not applicable to the recipient's role, and those
> rules whose names begin with "obs-" (e.g., obs-fold).
> """

I think we may improve the situation a little bit by indicating that
recipients must *detect* these obs-* rules even if they decide to reject
them because they can't parse them. The main issue I'm seeing with relaxing
parsing too much is the risk of seeing some smuggling attacks due to lazy
implementations that claim to be mostly compliant since they're not forced
to support line folding. We've already seen implementations which accept
spaces in header field names for example. I'm a bit worried about what the
following request would cause :

     POST /foo HTTP/1.1
     Host: foo
     Content-length: 8
     X-Dummy: yes
        Transfer-encoding: chunked

     ffffffff
     POST /unfiltered HTTP/1.1
     Host: foo
     Content-length: 100

     dangerous args

If a lazy implementation decides that the "   Transfer-Encoding" field
above is just "Transfer-Encoding", it might very well skip over the whole
4GB chunk, while for another implementation it would be the continuation
of X-Dummy.

So what do you think about the following change on top of yours :

 """
 If a received protocol element is processed, the recipient MUST be able to
 parse any value that would match the ABNF rules for that protocol element,
 excluding only those rules not applicable to the recipient's role, and those
 rules whose names begin with "obs-" (e.g., obs-fold). However, the recipient
 MUST be able to detect the rules it cannot parse and MUST reject such
 messages.
 """

Willy