[whatwg] Style sheet loading and parsing (over HTTP)
jonbarnett at gmail.com
Thu May 24 06:49:23 PDT 2007
On 5/24/07, Gervase Markham <gerv at mozilla.org> 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.
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg