Re: [whatwg/fetch] CORB: nosniff handling (#686)

> Since this only needs to apply to "no-cors", it seems changing the bit of step 5 of https://fetch.spec.whatwg.org/#concept-main-fetch that deals with "no-cors" would be more straightforward than duplicating same-origin and CORS checks. Although maybe you care about the ordering relative to CSP? In that event it seems that using request's response tainting would be easier?

Good idea.  I've removed CORS and same-origin checks from the CORB section.

I think only the last clause (the "otherwise" clause) in step 5 needs to be adjusted for CORB.  I think there is no need to change the "no-cors" clause, because "[opaque filtered response](https://fetch.spec.whatwg.org/#concept-filtered-response-opaque)" response already has a null body, so CORB cannot really add much here, right?

> What is the observable difference between an empty response and a response with some headers filtered and its body omitted?

Filtering out CORS headers leads to bad error messages in
http/tests/xmlhttprequest/origin-exact-matching/07.html layout tests.  Without CORB:

CONSOLE ERROR: line 1: Failed to load http://127.0.0.1:8000/xmlhttprequest/resources/access-control-allow-lists.php?origin=http%3A%2F%2Fwww2.localhost%3A8000: The 'Access-Control-Allow-Origin' header has a value 'http://www2.localhost:8000' that is not equal to the supplied origin. Origin 'http://localhost:8000' is therefore not allowed access.

With CORB:

CONSOLE ERROR: line 1: Failed to load http://127.0.0.1:8000/xmlhttprequest/resources/access-control-allow-lists.php?origin=http%3A%2F%2Fwww2.localhost%3A8000: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8000' is therefore not allowed access.

> I think the other thing we need is some description about what this means for implementation architectures to properly defend themselves. Maybe that can be done separately somehow though.

I think that choosing to implement CORB in a renderer process (VS in a browser/supervisor
process) is not observable and therefore such choice doesn't belong in a
normative part of a spec.  OTOH, I am open to covering this aspect separately,
in a non-normative part of a spec.

> We detect redirects using status code, so that should be good enough unless there are problems in the wild.

Okay - I've switched to using the 206 status code.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/686#issuecomment-383711732