<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:<br>> It's detrimental to the user when the user is denied content or a<br>> stylesheet for the content because a server is misconfigured.  There are<br>> cases, such as CSS documents and images referenced by CSS documents,
<br>> where ignoring Content-type is never harmful.  in other cases, the harm<br>> can be mitigated by the rules in the spec.<br><br>It's also detrimental to the user when they are put at security risk<br>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
<br>spam filtering software.<br><br>Obvious solution: if an attachment is uploaded by a user with no<br>permissions and its MIME type is one which contains script executed by<br>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
<br>better and ignores Content-Type.<br><br>Gerv<br></blockquote></div><br>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
<br><br>And then apply sniffing rules that take the Accept request header into account (including wildcards in the Accept header):<br>- 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.
<br>- If the Accept request header does accept text/html, and the Content-type response header is text/plain, it may be sniffed as HTML.<br><br>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.
<br><br>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