Closed Bug 702820 Opened 9 years ago Closed 9 years ago

Allow XHR to data URL

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla12

People

(Reporter: emk, Assigned: emk)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: dev-doc-complete, Whiteboard: [parity-Opera])

Attachments

(1 file, 1 obsolete file)

Per bug 699857, data URIs are considered as same-origin in Gecko.
We already allow XHR to blob URLs. Again, there is no point rejecting only data URLs.
This makes it harder for JavaScript libraries to detect HTML parsing support in XHR locally (without GETing an HTTP resource).
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Attachment #584323 - Flags: review?(bugs)
Comment on attachment 584323 [details] [diff] [review]
patch

Sicking should review all the CORS changes.

And this needs tests
Attachment #584323 - Flags: review?(bugs) → review?(jonas)
Comment on attachment 584323 [details] [diff] [review]
patch

The @font-face should possibly also use this new mechanism. It currently uses a different way to enable data-urls together with CORS-listeners.

However it's possible that the @font-face code needs to keep doing special things since it might want to sync-load data urls. If that's not the case, then please file a followup or attach another patch here.
Attachment #584323 - Flags: review?(jonas) → review+
I'm wondering if having xhr.status return 0 is a good idea. We do that file:// urls, and that's bitten me a number of times already
Blocks: 716489
> However it's possible that the @font-face code needs to keep doing special
> things since it might want to sync-load data urls. If that's not the case,
> then please file a followup or attach another patch here.
Files bug 716489.
(In reply to Ms2ger from comment #5)
> I'm wondering if having xhr.status return 0 is a good idea. We do that
> file:// urls, and that's bitten me a number of times already

FWIW, I have been confused by status returning 0 instead of 200 for successful non-HTTP responses. Maybe a follow-up bug?
(In reply to Henri Sivonen (:hsivonen) from comment #7)
> (In reply to Ms2ger from comment #5)
> > I'm wondering if having xhr.status return 0 is a good idea. We do that
> > file:// urls, and that's bitten me a number of times already
> 
> FWIW, I have been confused by status returning 0 instead of 200 for
> successful non-HTTP responses. Maybe a follow-up bug?

Filed bug 716491.
Attached patch patch v2Splinter Review
The previous patch caused test failure.
Also added a test case.
Try result:
https://tbpl.mozilla.org/?tree=Try&rev=4407d2e1a107
Attachment #584323 - Attachment is obsolete: true
Attachment #586993 - Flags: review?(jonas)
Keywords: checkin-needed
Hmm.  Do we really want to check for the "data" scheme here?  Or for the "inherits security context" flag?  Seems like the latter would make more sense to me....  (General note: any time you're checking string schemes the code is probably wrong.)
I'm not sure we should allow XHR to "wyciwyg:"/"javascript:" URIs.
(Opera do not allow XHR to "javascript:" URIs)
> I'm not sure we should allow XHR to "wyciwyg:"/"javascript:" URIs.

Why not?

And even if we grant that, do you want to allow it to all LOCAL_RESOURCE urls that inherit the security context?
Actually.... shouldn't this check just be identical to the SVG image stuff in nsDataDocumentContentPolicy::ShouldLoad?  That is, should XHR to a -moz-filedata URL, say, work?
XHR to blob URIs already works since Firefox 9.
(In reply to Masatoshi Kimura [:emk] from comment #14)
> XHR to blob URIs already works since Firefox 9.
Sorry, since Firefox 6 (that is, since MozBlobBuilder has been supported).
Depends on: 716820
Filed bug 716820 because Workers also check the hard-coded scheme name.
> XHR to blob URIs already works since Firefox 9.

OK, why?  What sort of check is _that_ doing?

Keep in mind that extensions can implement protocols too; the question is which of those XHR should work to.
(In reply to Boris Zbarsky (:bz) from comment #17)
> OK, why?  What sort of check is _that_ doing?
Apparently that's because blob URIs implement nsIURIWithPrincipal.
NS_SecurityCompareURIs will get a principal URI if the URI implements the interface.
For data URIs, NS_SecurityCompareURIs will fail because data URIs don't support nsIURIWithPrincipal and the scheme doesn't match with the loading document ("data" vs "http"/"file").
Ah, ok.  That makes sense.
http://hg.mozilla.org/integration/mozilla-inbound/rev/9f1349e72752
Flags: in-testsuite+
Keywords: checkin-needed
Target Milestone: --- → mozilla12
https://hg.mozilla.org/mozilla-central/rev/9f1349e72752
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Documented:

https://developer.mozilla.org/en/DOM/XMLHttpRequest#Gecko_notes

Mentioned on Firefox 12 for developers.
You need to log in before you can comment on or make changes to this bug.