the test site khanapp.com Content-Type: web; charset=utf-8 Both Chrome and Firefox handle this. http://mimesniff.spec.whatwg.org/ says "If the Content-Type header field is absent or if its value cannot be interpreted as a media type (e.g. because its value doesn't contain a U+002F SOLIDUS ('/') character), then there is no official-type." We should use sniffing here since the Content-Type is invalid.
Created attachment 175166 [details] Patch
Comment on attachment 175166 [details] Patch What's the problem here? 1) Just checking '/' isn't enough to identify all malformed MIME type strigns. 2) What is different between malformed MIME strings and unknown MIME strings? And why should we treat them differently?
Comment on attachment 175166 [details] Patch Also, if it does appear to be problem, we need a http test
(In reply to comment #0) > the test site khanapp.com > Content-Type: web; charset=utf-8 > > Both Chrome and Firefox handle this. Great... so if Chrome handles it at least one WebKit port does. Have you tried Safari? > http://mimesniff.spec.whatwg.org/ says "If > the Content-Type header field is absent or if its value cannot be interpreted > as a media type (e.g. because its value doesn't contain a U+002F SOLIDUS ('/') > character), then there is no official-type." I agree, that is the language of the spec. At least the snippet you include doesn't specify what browsers should do in this case. Do you have a bug to report here? In other words, is this causing problems at a real world site? > We should use sniffing here since the Content-Type is invalid. Some platforms sniff all network traffic (except for very specific scenarios) since the network is an untrusted place. Are you trying to fix only one specific platform here?
(In reply to comment #4) > (In reply to comment #0) > > the test site khanapp.com > > Content-Type: web; charset=utf-8 > > > > Both Chrome and Firefox handle this. > > Great... so if Chrome handles it at least one WebKit port does. Have you tried Safari? yes, safari also works. > > > http://mimesniff.spec.whatwg.org/ says "If > > the Content-Type header field is absent or if its value cannot be interpreted > > as a media type (e.g. because its value doesn't contain a U+002F SOLIDUS ('/') > > character), then there is no official-type." > > I agree, that is the language of the spec. At least the snippet you include doesn't specify what browsers should do in this case. > > Do you have a bug to report here? In other words, is this causing problems at a real world site? khanapp.com was the site reported, don't have other sites at hand. > > > We should use sniffing here since the Content-Type is invalid. > > Some platforms sniff all network traffic (except for very specific scenarios) since the network is an untrusted place. > > Are you trying to fix only one specific platform here? It looks only Qt/BlackBerry uses MIMESniffing.cpp, so with this patch, qt/blackberry will work the same way as firefox/chrome/safari. Besides, Chrome porting also uses similar solution in its mime_sniffer.cc to check if mimetype contains slash '/' and commented it's following firefox.
(In reply to comment #2) > (From update of attachment 175166 [details]) > What's the problem here? > 1) Just checking '/' isn't enough to identify all malformed MIME type strigns. > 2) What is different between malformed MIME strings and unknown MIME strings? And why should we treat them differently? "malform" would be too general, I will narrow down the subject. Come up with new patch...
Created attachment 175596 [details] Patch
(In reply to comment #5) > (In reply to comment #4) > It looks only Qt/BlackBerry uses MIMESniffing.cpp, so with this patch, qt/blackberry will work the same way as firefox/chrome/safari. Besides, Chrome porting also uses similar solution in its mime_sniffer.cc to check if mimetype contains slash '/' and commented it's following firefox. Apparently Chrome designed to match Firefox here. Saying it'll also act like Safari seems like a leap. Achieving the same end result as Safari does not mean the more thorough content-sniffing that's built in to Safari's networking library does it the same way. I'm still not convinced this patch is the right thing to do, but I won't r- it.
Comment on attachment 175596 [details] Patch Rejecting attachment 175596 [details] from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2 Last 500 characters of output: ueue/Source/WebKit/chromium/third_party/leveldatabase/src --revision 68 --non-interactive --force --accept theirs-conflict --ignore-externals' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' 38>At revision 68. ________ running '/usr/bin/python tools/clang/scripts/update.py --mac-only' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' ________ running '/usr/bin/python gyp_webkit' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' Updating webkit projects from gyp files... Full output: http://queues.webkit.org/results/15015552
Created attachment 177170 [details] Patch
Comment on attachment 177170 [details] Patch fix nit in change log
Comment on attachment 177170 [details] Patch Clearing flags on attachment: 177170 Committed r136361: <http://trac.webkit.org/changeset/136361>
All reviewed patches have been landed. Closing bug.