Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03

[Willy Tarreau <[e-mail]>]

On Sun, Jan 15, 2012 at 01:06:20PM -0800, Adam Barth wrote:
> On Sun, Jan 15, 2012 at 1:00 PM, Julian Reschke <[e-mail]> wrote:
> > On 2012-01-15 21:53, Adam Barth wrote:
> >> On Sun, Jan 15, 2012 at 12:41 PM, Willy Tarreau<[e-mail]>  wrote:
> >>> On Sun, Jan 15, 2012 at 11:52:38AM -0800, Adam Barth wrote:
> >>>> The requirement in the spec is what we intend.  The rule applies only
> >>>> to that exact octet sequence.
> >>>
> >>> But then what are the impacts of not matching the correct content-type ?
> >>
> >> I'm not sure I understand your question.  Can you explain a scenario
> >> in which something happens that causes someone to be sad with the
> >> current requirements?
> >
> > Translating Adam: matching only some specific header field instances is
> > intentional, as these are the ones we know misconfigured servers send.
> >
> > (right?)
> >
> > It wouldn't hurt if the spec would explain that choice, if it doesn't right
> > now.
> 
> I believe there's a ticket about adding that description.  We've been
> focusing more on the introduction/scope editing at the moment, but
> we'll get to this point.
> 
> More specifically, this is a workaround for an old (still widely
> deployed) version of Apache that used that exact octet sequence to
> identify resources for which it didn't know the MIME type.  Apache has
> since been changed to omit the Content-Type header in these cases, but
> old Apache installs stay around for a very, very long time.  Matching
> this exact octet sequence is the minimum injury way of dealing with
> this legacy content.

OK I think I'm getting it now.

I assumed that at step 2 of section 4, the matching text was constituting
the official-type, which apparently it's not. Getting it wrong at this
point causes a jump to the "unknown type" section.

Maybe some names should be changed (eg: "content-type" instead of
"official-type") to make it easier to read. Confusion is too easy this
way and immediately makes code derived from a wrong interpretation to
be buggy :-(

Regards,
Willy