Cannot get next URL for redirect="manual"

[askoretskiy]

When you use redirect="manual" there is not way to get the new URL, i.e. to where response was redirected.

Example for Firefox:

fetch("/account/", {
    credentials: 'same-origin',
    redirect: 'manual',
}).then(response => {
    console.log(response);
});

Server would response with redirect to /login/?next=/account/.

Here is Javascript Response object:

{
bodyUsed: false,
headers: {},
ok: false,
redirected: false,
status: 0,
​​statusText: "",
​​type: "opaqueredirect",
​​url: "http://localhost:8000/account/"
}

So response.url is the URL I requested.

How could I get the URL where response was redirected to? There is no "redirect_url" and headers are empty.

As far as I understand the specification, with "manual" is meant to handle redirects manually. Then there should be a way to get this new URL and do another request to this new URL.

Here is what server send:

HTTP/1.1 302 Found
X-Powered-By: Express
date: Thu, 14 Jun 2018 09:41:49 GMT
server: WSGIServer/0.2 CPython/3.7.0b5
content-type: text/html; charset=utf-8
location: /login/?next=/account/
x-frame-options: SAMEORIGIN
content-length: 0
vary: Accept-Language, Cookie
content-language: en
connection: keep-alive

How to access this new url /login/?next=/account/?

[annevk]

That is by design: https://fetch.spec.whatwg.org/#atomic-http-redirect-handling. This feature is useful in combination with service workers.

[askoretskiy]

Maybe documentation of “redirect” block should be extended to reduce confusion? For example, a link to the url you provided?

What about renaming “manual” to false or “disabled” or “no-follow”? Current name gives wrong expectations, since you cannot handle redirects manually. It just do not follow, indicate it got redirect and do not raise an error.

[annevk]

I wouldn't mind a link. It might also help to state that it's primarily for handling navigation requests (which do redirects manually in a sense) in service workers.

Unfortunately renaming this at this point is too late as browsers have shipped the functionality, but I do agree that we made a bad call there. Mea culpa!

[askoretskiy]

👍

[askoretskiy]

By the way, it would be great if provide an example how redirect=“manual” could be used with service workers for navigation. At least an idea.

Did you mean service workers that handle browser requests so that we app e. g. could work offline?

That would be helpful for devs.

[annevk]

Say the user navigates to /test. The service worker for that scope intercepts the fetch and forwards it to the server. The server responds with a redirect to /somewhere-else. If the service worker returns that redirect the browser will then navigate to /somewhere-else`, potentially hitting the same service worker or another. (The service worker could store these responses so this kind of redirect would also function offline.)

Note that typically redirects are followed for fetches (e.g., from <img>, <script>, fetch() by default), but navigation explicitly doesn't want to follow redirects because we might want to ask a different service worker to handle the request as the scope or origin can change.

Note that the browser does get to see the contents of the redirect, but nobody else does per the aforementioned link.

[wanderview]

Hmm, I have to admit I thought someone directly calling fetch(url, { redirect: "manual" }) from the main thread would be able to walk the redirect chain themselves. I guess I was confused when we added the manual redirect stuff.

[annevk]

We could offer that if the redirect response opts out of being opaque as per #601.

[Radiergummi]

So, excuse me for digging out this old issue, but I'd just like to confirm this assumption: There is currently no way to get a hold of the Location header if a response has been redirected? This is quite annoying when implementing progressively enhanced login forms - I would have liked to capture form submissions, show errors on failure or redirect manually on success.

[annevk]

That is correct, we could perhaps add an opt-in header for that as per #601.