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)
8.83 KB,
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.
Comment 1•13 years ago
|
||
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.
Comment 7•13 years ago
|
||
(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•12 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
•