702820 - Allow XHR to data URL

Status: RESOLVED FIXED

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

Description

[Masatoshi Kimura [:emk]]

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.

Comment 1

[Henri Sivonen (:hsivonen)]

This makes it harder for JavaScript libraries to detect HTML parsing support in XHR locally (without GETing an HTTP resource).

Comment 2

[Masatoshi Kimura [:emk]]

Attachment: patch

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 584323 [details] [diff] [review]
patch

Sicking should review all the CORS changes.

And this needs tests

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 5

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

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

Comment 6

[Masatoshi Kimura [:emk]]

> 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.

Comment 7

[Henri Sivonen (:hsivonen)]

(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?

Comment 8

[Masatoshi Kimura [:emk]]

(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.

Comment 9

[Masatoshi Kimura [:emk]]

Attachment: patch v2

The previous patch caused test failure.
Also added a test case.
Try result:
https://tbpl.mozilla.org/?tree=Try&rev=4407d2e1a107

Comment 10

[Boris Zbarsky [:bzbarsky]]

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.)

Comment 11

[Masatoshi Kimura [:emk]]

I'm not sure we should allow XHR to "wyciwyg:"/"javascript:" URIs.
(Opera do not allow XHR to "javascript:" URIs)

Comment 12

[Boris Zbarsky [:bzbarsky]]

> 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?

Comment 13

[Boris Zbarsky [:bzbarsky]]

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?

Comment 14

[Masatoshi Kimura [:emk]]

XHR to blob URIs already works since Firefox 9.

Comment 15

[Masatoshi Kimura [:emk]]

(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).

Comment 16

[Masatoshi Kimura [:emk]]

Filed bug 716820 because Workers also check the hard-coded scheme name.

Comment 17

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 18

[Masatoshi Kimura [:emk]]

(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").

Comment 19

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  That makes sense.

Comment 20

[Dão Gottwald [:dao]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/9f1349e72752

Comment 21

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/9f1349e72752

Comment 22

[Eric Shepherd [:sheppy]]

Documented:

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

Mentioned on Firefox 12 for developers.