[Bug 7744] Is sniffing required?

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7744





--- Comment #21 from Maciej Stachowiak <mjs@apple.com>  2010-02-09 10:56:22 ---
(In reply to comment #20)
> "... it recommends that UAs should not sniff, but if they do, they
> should use this specific algorithm, not any others. HTML5 does not want that
> set of recommendations (either don't sniff, or if you do, use this algorithm)
> to be optional, though specifically choosing the sniffing side of that fork is
> optional...."
> 
> It is nonsensical to say that "HTML5 does not want". There is no entity "HTML5"
> that "wants" something. If sniffing is optional (that either sniffing or not
> sniffing areconforming), there is no reason why it should be non-complaint to,
> say, sniff for HTML when confronted with text/plain but not sniff for PDF when
> given text/plain.   The "all or nothing" advice on sniffing is inappropriate.
> 
> This is a comment on draft-abarth-mime-sniff-04 but is also a comment on the
> HTML specification from which it was derived.  
> 
> Trying to provide an exact algorithm for sniffing makes this difficult to fix;
> the right fix is to eliminate the algorithm and make normative constraints on
> the results instead.
> 

If you read the full introduction to draft-abarth-mime-sniff, you will see that
it gives good security justification for using its particular sniffing rules
and not some other set. I do not know if all those same security considerations
would apply to using a subset of the rules. I do know that if UAs add their own
rules, or use arbitrary other ones, then that is definitely a potential source
of security problems. Perhaps that is a comment to raise on the mimesniff
draft. In any case I don't think that trying to address that issue of what
specific constraints should be placed on sniffing algorithms is best addressed
by adding more optionality at the HTML5 level would not be a very good
solution.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 9 February 2010 10:56:25 UTC