On 5/24/07, Gervase Markham <[EMAIL PROTECTED]> wrote:
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. Recent example: spammers, phishers and other sundry evildoers have started attaching HTML attachments to Bugzilla installations, and using 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". This is the least intrusive option - the attachment can still be viewed, and someone with permissions can change the MIME type later after checking the content. However, this doesn't protect anyone using IE, because IE claims to know better and ignores Content-Type. Gerv
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". I would propose that the "type" attribute be more meaningful on, for example, the <a> element and the <object> element: - 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. -- Jon Barnett
