<br><br><div><span class="gmail_quote">On 5/24/07, <b class="gmail_sendername">Gervase Markham</b> <<a href="mailto:gerv@mozilla.org">gerv@mozilla.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Jon Barnett wrote: > It's detrimental to the user when the user is denied content or a > stylesheet for the content because a server is misconfigured.  There are > cases, such as CSS documents and images referenced by CSS documents,

> where ignoring Content-type is never harmful.  in other cases, the harm > can be mitigated by the rules in the spec. It's also detrimental to the user when they are put at security risk because MIME types are not respected.

<br><br>Recent example: spammers, phishers and other sundry evildoers have<br>started attaching HTML attachments to Bugzilla installations, and using<br>them as redirectors to their sites, to avoid domain name blacklists in

spam filtering software. Obvious solution: if an attachment is uploaded by a user with no permissions and its MIME type is one which contains script executed by the browser (all HTML types, SVG, ...) then change it to "text/plain".

<br>This is the least intrusive option - the attachment can still be viewed,<br>and someone with permissions can change the MIME type later after<br>checking the content.<br><br>However, this doesn't protect anyone using IE, because IE claims to know

better and ignores Content-Type. Gerv </blockquote></div> if I read the current draft correctly, that resource should still be sniffed as text/plain.  That's what I meant by "the harm can be mitigated by the rules in the spec".

<br><br>I would propose that the "type" attribute be more meaningful on, for example, the <a> element and the <object> element:<br>- If the "type" attribute is present, the UA must use its value as the value of the Accept request header when requesting a resource

And then apply sniffing rules that take the Accept request header into account (including wildcards in the Accept header): - If the Accept request header accepts text/plain and not text/html, and the Content-type response header is text/plain, it must not be sniffed as HTML.

- If the Accept request header does accept text/html, and the Content-type response header is text/plain, it may be sniffed as HTML. That would allow, for example, Bugzilla to use <a type="text/plain"> when linking to an attachment without fear that the attachment might be sniffed as text/html.

I don't know how that would break existing content, but I did want to mention it.  I don't think the "type" attribute is currently abused, especially on links, in a way that would make this harmful.

<br><br>-- <br>Jon Barnett