Closed
Bug 702820
Opened 13 years ago
Closed 13 years ago
Allow XHR to data URL
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
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)
(deleted),
patch
|
sicking
:
review+
|
Details | Diff | Splinter Review |
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).
Assignee | ||
Comment 2•13 years ago
|
||
Comment 3•13 years ago
|
||
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+
Comment 5•13 years ago
|
||
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
Assignee | ||
Comment 6•13 years ago
|
||
> 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?
Assignee | ||
Comment 8•13 years ago
|
||
(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.
Assignee | ||
Comment 9•13 years ago
|
||
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)
Attachment #586993 -
Flags: review?(jonas) → review+
Assignee | ||
Updated•13 years ago
|
Keywords: checkin-needed
Comment 10•13 years ago
|
||
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.)
Assignee | ||
Comment 11•13 years ago
|
||
I'm not sure we should allow XHR to "wyciwyg:"/"javascript:" URIs. (Opera do not allow XHR to "javascript:" URIs)
Comment 12•13 years ago
|
||
> 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•13 years ago
|
||
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?
Assignee | ||
Comment 14•13 years ago
|
||
XHR to blob URIs already works since Firefox 9.
Assignee | ||
Comment 15•13 years ago
|
||
(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).
Assignee | ||
Comment 16•13 years ago
|
||
Filed bug 716820 because Workers also check the hard-coded scheme name.
Comment 17•13 years ago
|
||
> 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.
Assignee | ||
Comment 18•13 years ago
|
||
(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•13 years ago
|
||
Ah, ok. That makes sense.
Comment 21•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/9f1349e72752
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Keywords: dev-doc-needed
Depends on: 727530
Comment 22•12 years ago
|
||
Documented: https://developer.mozilla.org/en/DOM/XMLHttpRequest#Gecko_notes Mentioned on Firefox 12 for developers.
Keywords: dev-doc-needed → dev-doc-complete
You need to log in
before you can comment on or make changes to this bug.
Description
•