On Sun, Jan 15, 2012 at 01:06:20PM -0800, Adam Barth wrote: > On Sun, Jan 15, 2012 at 1:00 PM, Julian Reschke <julian.resc...@gmx.de> wrote: > > On 2012-01-15 21:53, Adam Barth wrote: > >> On Sun, Jan 15, 2012 at 12:41 PM, Willy Tarreau<w...@1wt.eu> 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 _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec