This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25190 - Sniffing empty payloads unclear
Summary: Sniffing empty payloads unclear
Status: RESOLVED MOVED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: MIME (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: Unsorted
Assignee: Gordon P. Hemsley
QA Contact: sideshowbarker+mimespec
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-28 10:20 UTC by Robin Berjon
Modified: 2019-03-30 19:59 UTC (History)
3 users (show)

See Also:


Attachments

Description Robin Berjon 2014-03-28 10:20:59 UTC
It is unclear to me what empty payloads with no labelling content-type are supposed to be sniffed as.

Following the algorithm, I eventually reach:

"""
9. If the resource header contains no binary data bytes, the sniffed MIME type is "text/plain". Abort these steps. 
10. The sniffed MIME type is "application/octet-stream". 
"""

It's not entirely clear that if the resource header contains nothing then it can be said to contain no binary data bytes. (Or rather, at the very least the case seems to be treated differently by implementations.)

In testing of such a resource (loaded into an iframe), Gecko prompts for download whereas Blink, WebKit, and Trident all report the document.contentType as undefined.

It would be worth deciding what empty unlabelled payloads should sniff as.
Comment 1 Gordon P. Hemsley 2014-03-29 15:47:24 UTC
Ah, the case of the empty string (well, the empty byte sequence, in this case) strikes again!

It's an interesting issue. And, as always, we have the difference between what UAs "should" do, and (the consensus of) what UAs *actually* do.

It seems to me that the empty byte sequence would trivially contain no binary data bytes (as it contains no bytes at all), which would sniff it as 'text/plain' and should display as an empty text document in a browsing context.

On the other hand, having no bytes at all, one could also make the case that the resource is not a text resource and should be sniffed as 'application/octet-stream'.

I don't think mimesniff currently defines the behavior of document.contentType, but I don't think it should ever be undefined if the sniffing algorithm is used. Even if nosniff is turned on, a resource without a supplied MIME type (i.e. "a resource with an unknown MIME type") is sniffed regardless, and the "rules for identifying an unknown MIME type" never returns undefined.

In the UAs that have the document.contentType of the empty resource return undefined, does the iframe display an empty document? (If so, that would suggest it it would be best to maintain the 'text/plain' result.) Does the Gecko download prompt give any indication as to what MIME type it thinks the document is? (I'm predicting that it treats it as 'application/octet-stream'.)
Comment 2 Simon Pieters 2015-01-13 09:01:18 UTC
Note to someone(TM) to check https://critic.hoppipolla.co.uk/showcomment?chain=3535 when this bug is resolved.