Closed Bug 1136200 Opened 9 years ago Closed 9 years ago

Verify request type is no-cors if Service Worker returns opaque response.

Categories

(Core :: DOM: Workers, defect)

33 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla39
Tracking Status
firefox39 --- fixed

People

(Reporter: nsm, Assigned: nsm)

References

Details

Attachments

(1 file, 1 obsolete file)

Mentor: nsm.nikhil
Whiteboard: [good first bug][lang=C++]
"no-cors" mode is used, for example, when a page has an <img> tag with src="http://someotherOrigin.com" where the image is displayed, or canvas where you may set the bitmap to another origin but then may no longer access the data.

If a service-worker returns an opaque Response it must have been in response to a Request with mode "no-cors".

Implement Section 4.2 step 2.2 - https://fetch.spec.whatwg.org/#http-fetch

1) In dom/fetch/ServiceWorkerEvents.cpp, in the ResolvedCallback(), after unwrapping the Response check that if the initiating Request (the implementer will have to add some way to get at the FetchEvent's Request, or just track what the Request's mode was) has mode no-cors and Response's Type() is not opaque, to just return.

2) Write a test case using mochitest in dom/workers/test/serviceworkers/fetch/fetch_tests.js to add a call to fetch("crossOriginURL", { mode: "no-cors" }). There are a couple of tests.
a) no-cors request, sw returns opaque response -> pass
b) "same-origin" request, sw returns opaque response -> error
Whiteboard: [good first bug][lang=C++]
Assignee: nobody → nsm.nikhil
Mentor: nsm.nikhil
Attached file MozReview Request: bz://1136200/nsm (obsolete) —
/r/5547 - Bug 1136200 - Verify request type is not no-cors if response is opaque

Pull down this commit:

hg pull review -r 17ea7e7061bf0814a0b3f13fc8b94b3679545af8
Attachment #8578876 - Flags: review?(josh)
Comment on attachment 8578876 [details]
MozReview Request: bz://1136200/nsm

https://reviewboard.mozilla.org/r/5545/#review4551

::: dom/workers/ServiceWorkerEvents.cpp
(Diff revision 1)
>      return;

This isn't a network error, is it? Doesn't this make the original request go through unintercepted?
Attachment #8578876 - Flags: review?(josh)
Comment on attachment 8578876 [details]
MozReview Request: bz://1136200/nsm

https://reviewboard.mozilla.org/r/5545/#review4683

Ship It!
Attachment #8578876 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/2e4fa9ce9708
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: