This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1173 [details] 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.
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).
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 ?
(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 [details].
@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 [details]. It is part of a larger test that I'm writing for the slice method.
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//");
(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 :) )
(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?
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>.
(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.
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.