Bug 18529 - Existence of separators in token should throw SyntaxError
Existence of separators in token should throw SyntaxError
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: File API
unspecified
All All
: P2 normal
: ---
Assigned To: Arun
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-10 18:07 UTC by Saurabh Anand
Modified: 2012-10-15 18:05 UTC (History)
3 users (show)

See Also:


Attachments
Test Case (661 bytes, text/html)
2012-08-10 18:07 UTC, Saurabh Anand
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Saurabh Anand 2012-08-10 18:07:40 UTC
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.
Comment 1 Arun 2012-08-10 19:04:15 UTC
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).
Comment 2 Saurabh Anand 2012-08-10 19:21:29 UTC
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 ?
Comment 3 Arun 2012-08-10 20:37:11 UTC
(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].
Comment 4 Saurabh Anand 2012-08-10 21:29:08 UTC
@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.
Comment 5 Jonas Sicking 2012-08-11 01:38:53 UTC
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//");
Comment 6 Arun 2012-08-11 23:35:21 UTC
(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 :) )
Comment 7 Jonas Sicking 2012-08-12 03:50:36 UTC
(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?
Comment 8 Ms2ger 2012-08-12 07:10:47 UTC
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>.
Comment 9 Arun 2012-09-06 21:12:21 UTC
(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.
Comment 10 Arun 2012-10-15 18:05:25 UTC
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.