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

Hi Mark,

Sorry for being silent so long, I was quite busy last two weeks :-/

On Sun, Jan 20, 2013 at 01:37:26PM +1100, Mark Nottingham wrote:
> Anyone? Bueller?
> 
> To make it clear -- I propose we downgrade recipient support for OBS-FOLD to
> a prose recommendation. 

Given the security impact it can have if processed the lazy way, we must at
least have something normative. Practically, I don't know how this can be
put into valid terms in a spec, but I'd like to see something which mandates
detecting OBS-FOLD and then leaves the choice to the implementation to accept
it or to reject the message. What I don't want to see is implementations which
consider that the space is part of the next header field name, and which later
trim the spaces and take this header field for another one. And we know for
sure that lazy implementations are lazy in multiple areas (typically all
those quickly written in scripting languages).

> Am happy to hear well-reasoned opinions to the contrary (but see note about interop testing below).

(...)
> > Right now, we have:
> >  obs-fold - senders MUST NOT generate, recipients MUST accept
> >  obs-text - new headers SHOULD NOT use, recipients SHOULD treat as opaque data 
> >  obs-date - sender MUST NOT generate (implied by MUST), recipient parsers MUST accept
> > 
> > obs-fold was a "recipients SHOULD accept" before Roy's change. 
> > 
> > I suppose we could come up with a more rigid definition of what "obs-" means here, but that seems like it's sort of diminishing returns.
> > 
> > The issue here, I think, is whether or not we're requiring recipients to deal with line folding.
> > 
> > Some quick and dirty testing shows it's not interoperable. By sending requests in this form:
> > 
> > GET / HTTP/1.1
> > Host:
> >    [hostname]
> > User-Agent: Foo/1.0
> > 
> > which our ABNF currently allows, I got errors on several sites. Given that,
> > I wonder why requiring it to be accepted is necessary; making those sites
> > non-conformant (as well as any clients that behave in a similar manner)
> > isn't going to improve interop, and this feature isn't used in practice any
> > way, precisely because it doesn't get interop. 

I'm not so much worried by these ones which possibly have not found their Host
header field as I am by the ones which accept the following message without
yelling :

   POST / HTTP/1.1
   Host: [hostname]
   User-Agent: foo/1.0
     Transfer-encoding: chunked
   Content-Length: 10

Everything here is valid, the transfer-encoding is the continuation of the
User-Agent header which was folded. But if middle boxes don't support folding,
they'll have a "  Transfer-encoding" header field with value "chunked", which
if interpreted as "Transfer-encoding" will have precedence over Content-Length.

So I think that we have valid reasons to be concerned about just leaving a
SHOULD there.

Maybe we can have a "SHOULD" with an "IF" and a "MUST" ? Eg: "IF an
implementation decides not to implement obs-fold, then it MUST take
extreme care to reject a message which contains a line beginning with
SP/TAB" ? I know that such characters are already not allowed, but
things are spread over so many sheets that it's hard to get all the
things right at once. And here we want specific care about a real risk.

> > SHOULD makes sense; I could even see downgrading it to prose. I don't
> > understand why this is a MUST, if we don't get good interop on it now, and
> > it's not a feature that's in-demand, widely used, or important, AFAIK.

It's so much complicated to get right in line-based parsers (eg: shell
scripts) that the MUST seems excessive to me if there are no provisions
for not doing it at all.

> > The same logic could be applied to obs-date, but I don't have hard data on
> > how interoperable it is; AFAIK most implementations do a good job of
> > covering the three possible formats.

I'm fairly certain I've already seen this old format as a past expiration
date for a cookie in an old application. Rejecting such formats could have
the effect of not removing cookies upon logout, which may be of little
inconvenience to some applications.

> > The text around obs-text seems right, because it's such a different case.

Agreed, and we need to keep it.

Regards,
Willy

Received on Sunday, 20 January 2013 07:45:04 UTC