18529 2012-08-10 18:07:40 +0000 Existence of separators in token should throw SyntaxError 2012-10-15 18:05:25 +0000 1 1 1 Unclassified WebAppsWG File API unspecified All All RESOLVED FIXED P2 normal --- 1 saurabhanandiit arun jonas Ms2ger public-webapps public-webapps-bugzilla oldest_to_newest 72050 0 1173 saurabhanandiit 2012-08-10 18:07:40 +0000 Created attachment 1173 Test Case http://tools.ietf.org/html/rfc2616#section-3.7 says that media-type should be type "/" subtype *( ";" parameter ) , where type and subtype both are tokens. http://tools.ietf.org/html/rfc2616#page-17 says that tokens should not contain CTL's or separators, hence according to section 4.B.d of http://dev.w3.org/2006/webapi/FileAPI/#slide-method-algo, it should throw a SyntaxError, but it does not. I feel the spec doesn't match implementation. 72055 1 arun 2012-08-10 19:04:15 +0000 Cc'ing Jonas for Firefox. I wonder if mandating throwing is too strict a condition. It makes sense, but I'd rather not spec. fiction. Note that the sample needs to be rewritten a bit. Also, the original reporter should file this bug under Chromium's bug database and under Mozilla's bug database (bugzilla.mozilla.org). 72056 2 saurabhanandiit 2012-08-10 19:21:29 +0000 Hi Arun, (In reply to comment #1) > Cc'ing Jonas for Firefox. > > I wonder if mandating throwing is too strict a condition. It makes sense, but > I'd rather not spec. fiction. > > Note that the sample needs to be rewritten a bit. Which sample are you referring to ? 72060 3 arun 2012-08-10 20:37:11 +0000 (In reply to comment #2) > Hi Arun, > > (In reply to comment #1) > > Cc'ing Jonas for Firefox. > > > > I wonder if mandating throwing is too strict a condition. It makes sense, but > > I'd rather not spec. fiction. > > > > Note that the sample needs to be rewritten a bit. > Which sample are you referring to ? I meant attachment 1173. 72064 4 saurabhanandiit 2012-08-10 21:29:08 +0000 @Arun, I've filed both Chromium (https://code.google.com/p/chromium/issues/detail?id=141922) and Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=781896) issues. What is the improvement that you are suggesting for attachment 1173. It is part of a larger test that I'm writing for the slice method. 72071 5 jonas 2012-08-11 01:38:53 +0000 I'd rather not get into the business of enforcing correct mimetypes. That rabbit hole can go deep once you start considering that different mimetypes accept different parameters. I'd rather just treat the mimetype as an opaque string and forward it to whatever API that is using the mimetype. So for example if a page does xhr = new XMLHttpRequest(); xhr.open("GET", URL.createObjectURL(new Blob(..., ";;foopy//"))); xhr.send(); in this case the XHR code already has to be able to deal with malformed incoming mimetypes since the server could be sending anything. Likewise a page could do xhr = new XMLHttpRequest(); xhr.open("GET", uri); xhr.send(new Blob(..., ";;foopy//")); which isn't that different from a page calling xhr.setRequestHeader("Content-Type", ";;foopy//"); 72082 6 arun 2012-08-11 23:35:21 +0000 (In reply to comment #5) > I'd rather not get into the business of enforcing correct mimetypes. That > rabbit hole can go deep once you start considering that different mimetypes > accept different parameters. > > I'd rather just treat the mimetype as an opaque string and forward it to > whatever API that is using the mimetype. So what each API does with mimetypes is actually inconsistent! I think that by throwing, we make it clear what *this* API does and doesn't allow. On the other hand, it does involve parsing mimetype strings; other bugs have been logged showing inconsistency RFC2616. I'd still rather throw, unless you feel strongly that this is too strong (or of course if you feel strongly that this will never be implemented and that the bug mentioned in Comment 4 will be marked WONTFIX :) ) 72084 7 jonas 2012-08-12 03:50:36 +0000 (In reply to comment #6) > I think that by throwing, we make it clear what *this* API does and doesn't > allow. Can you elaborate on what you mean by this? 72085 8 Ms2ger 2012-08-12 07:10:47 +0000 Additional data point: Opera, Chrome and Firefox all fail the exact same tests of <http://w3c-test.org/webapps/FileAPI/tests/submissions/Mozilla/slice.html>. 73367 9 arun 2012-09-06 21:12:21 +0000 (In reply to comment #7) > (In reply to comment #6) > > I think that by throwing, we make it clear what *this* API does and doesn't > > allow. > > Can you elaborate on what you mean by this? I mean simply that we make it clear that you can only coin a valid mimetype string; if you don't, the application throws. Should I remove the fiction that we should validly parse for mimetypes (such as http://dev.w3.org/2006/webapi/FileAPI/#dfn-contentTypeBlob) and merely say that it SHOULD be an RFC2616 mimetype? It's clear from Comment 8 that implementations don't respect this anyway. I'm disappointed, but can remove it. 76321 10 arun 2012-10-15 18:05:25 +0000 We've decided to treat type as an opaque string. Implementations don't throw; browser developers are reluctant to throw, and thus validation against the RFC is not useful. 1173 2012-08-10 18:07:40 +0000 2012-08-10 18:07:40 +0000 Test Case Blob-slice.html text/html 661 saurabhanandiit PCFET0NUWVBFIGh0bWw+CjxtZXRhIGNoYXJzZXQ9dXRmLTg+Cjx0aXRsZT5CbG9iIHNsaWNlPC90 aXRsZT4KPGxpbmsgcmVsPWhlbHAgaHJlZj0iaHR0cDovL2Rldi53My5vcmcvMjAwNi93ZWJhcGkv RmlsZUFQSS8jc2xpZGUtbWV0aG9kLWFsZ28iPgo8c2NyaXB0IHNyYz0iL3Jlc291cmNlcy90ZXN0 aGFybmVzcy5qcyI+PC9zY3JpcHQ+CjxzY3JpcHQgc3JjPSIvcmVzb3VyY2VzL3Rlc3RoYXJuZXNz cmVwb3J0LmpzIj48L3NjcmlwdD4KPGRpdiBpZD0ibG9nIj48L2Rpdj4KPHNjcmlwdD4KLy8gRXhw ZWN0ZWQgUmVzdWx0IDogdHlwZS9zdWJ5cGUgYXJlIHRva2Vucywgd2hpY2ggYXJlIG5vdCBhbGxv d2VkIHRvIGNvbnNpc3Qgb2Ygc2VwYXJhdG9ycywgYW5kIHNob3VsZCB0aHJvdyBTeW50YXhFcnJv cgovLyBBY3R1YWwgUmVzdWx0IDogRG9lcyBub3QgdGhyb3cKdGVzdChmdW5jdGlvbigpIHsKICB2 YXIgYmxvYlRlbXAgPSBuZXcgQmxvYihbIlBBU1MiXSk7CiAgYXNzZXJ0X3Rocm93cyhuZXcgU3lu dGF4RXJyb3IoKSwgZnVuY3Rpb24oKSB7CiAgICBibG9iVGVtcC5zbGljZSgwLCA0LCAidGUoeHQv cGxhaW4iKTsKICB9KTsKfSwgInR5cGUgY29uc2lzdHMgb2YgYW55IENUTHMgb3Igc2VwYXJhdG9y cywgdGhyb3cgU3ludGF4RXJyb3IiKTsKPC9zY3JpcHQ+Cg==