W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2014

[whatwg] Handling of redirect responses to non-simple CORS requests

From: Utkarsh Upadhyay <musically.ut@gmail.com>
Date: Sun, 29 Jun 2014 17:59:18 +0200
Message-ID: <CALh3q9weDbspXrN7axBCXgM55YaL6k4DcBwi=xcQauM3=DSDTg@mail.gmail.com>
To: whatwg@whatwg.org

I want to know the rationale of a rule in the Fetch Standard for HTTP Fetch
[1]. I tried searching the archives but could not find any discussions
pertaining to it.

While handling redirects (30x) returned as a response to a CORS request
which had needed a pre-flight request, I understand that the following rule
takes effect:

> *Step 9:* If the CORS preflight flag is set, set response's type to error
and set request's manual redirect flag.

What Bad Things (tm) could happen if we do allow such redirects? What if we
allow redirects to _locationURL_ which are allowed if the request's mode
was _same-origin_?


Motivation: I wanted to build a delay proxy as a developer tool. The proxy
(sitting on a separate domain) would receive a request with the target URL
as a parameter, wait for a certain period, and then return the correct CORS
headers with a redirect to the target URL (which usually would be
`localhost` or the same domain which initiated the request).

However, because all redirect responses to non-simple HTTP requests result
in error, this cannot work except for GET (and HEAD?) requests. Now I am
interested in finding out why this decision was made.



PS: I also posted this question on StackOverflow [2].

[1]: http://fetch.spec.whatwg.org/#http-fetch
Received on Sunday, 29 June 2014 16:00:07 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:21 UTC