[whatwg] Style sheet loading and parsing (over HTTP)

[Jon Barnett]

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.
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070524/b27e8ea7/attachment-0001.htm>