Ian Hickson wrote:
Since the whole point of text/plain sniffing is a workaround around a
known issue where content is reliably mis-marked as text/plain, and
since in this case there is a source of MIME information that's more
reliable than that, it's not clear to me why we want to continue
sniffing.
Of course if there is no @type there is no problem; I'm specifically
concerned about the @type="text/plain" case here.
What exactly are you proposing here?
- Always honour type="" if it's a UA-supported type, ignoring server-
provided content-type?
- Always honour type="" without sniffing if it matches the server-
provided content-type, even if normally that type would be sniffed?
- Just honour type="text/plain" regardless of the server type, but for
other UA-supported type=""s, use the server type?
My suggestion is to only perform text/plain "is this text or binary"
sniffing where it belongs: on the HTTP level; since it's a workaround
for a particular HTTP server bug. It shouldn't affect other type metadata.
Perform the sniffing such that it detects as either text/plain or
application/octet-stream.
Then if it's application/octet-stream we'll end up using the @type.
Though see below on other sniffing issues.
This does fail to sniff text/plain as the various "non-scriptable"
types, but I question how desirable that is anyway, honestly. If we
want to preserve this property without clobbering @type="text/plain"
then I need to think a bit more about how to specify the behavior here.
Maybe your option 2 is what would give that behavior... I can work
through it if you'd like.
Your option 1 would be ok if that's what we want (but a change from
HTML4 and what UAs at least _try_ to implement now; I'm not sure whether
it's desirable on its own). Your option 3 is a bit too magic for
text/plain in @type; unnecessarily so unless we want to go the full
option 1 route. All in my opinion, of course.
My concern about text/plain data being sniffed as text/html by your
current algorithm (even with the changes you've made) seems to remain
unaddressed.
I thought I had. Can you walk me through how anything labeled text/plain
could get sniffed as text/html with the new text?
Hmm. Assume the type attribute is not set and HTML data is sent as
text/plain and contains a "binary byte" in the first 512 bytes (can just
stick it in the <title> or something). Also assume no plug-in claims to
support the URI's file extension.
At step 3, the resource type is set to text/plain.
At step 4, the resource type is sniffed as application/octet-stream,
since text/html is marked as scriptable in [MIMESNIFFF].
At step 5, there is no @type, and the resource type is
application/octet-stream, so the resource type is changed to unknown.
At step 6, nothing changes since there is no plug-in supporting the
URI's file extension.
At step 7, the resource type is "unknown", so it is changed to the
"sniffed type of the resource".
Maybe I simply misunderstood this last reference, by way of contrasting
it with what step 4 says and you mean to apply the full sniffing
algorithm, including the special-cases for text/plain, and not just
section 5 of [MIMESNIFF]. In that case there wouldn't be a problem (the
data would get sniffed as application/octet-stream). That wasn't quite
clear, but I can see now that this is probably what you meant.
-Boris
