How does networkFetch handle redirects?

[jakearchibald]

If a redirect is issued, I want to know about it in case it's a captive portal.

[annevk]

I think we should offer an API that does not follow redirects automatically.

I also think that networkFetch (which should just be fetch) should not be introduced by this specification, but I guess it's fine for now so we have something to reason about.

[jakearchibald]

Without it we're unable to do AppCache's FALLBACK feature. As in, try the network & do something else on failure.

[annevk]

All I'm saying is that you don't want to put all these different features that make a lot of sense outside this specific worker context as well, in the same specification. Because at that point you're doing the much feared scenario solving rather than building a layered architecture.

[jakearchibald]

Ahh yes, makes sense

[slightlyoff]

...but we can't solve this via XHR, so we need something that returns Response objects and takes Request objects as parameters. The idea of simply punting without explaining what to do doesn't work. It's de-facto layered in the sense that networkFetch() is clearly doing what the lower layer does. I'm happy to bikeshed it to oblivion, though.

As for who introduces fetch(), is that really something to argue about? I don't care, and I'm pretty sure you don't either...assuming the API is sane and does what you like. In any case, calling it networkFetch() or httpFetch() (my preferred name now) at least gives us a plausible way to avoid the naming conflict when we introduce fetch() everywhere. If we like what we get out of the design exercise so much that it becomes the fetch() API signature, so much the better! We just deprecate httpFetch() (or remove it, depending on when we make the cut over).

[slightlyoff]

per today's f2f, regarding the basic policy, we decided:

• documents don't see redirects for fetches they generate
• service workers get sent both initial fetches and fetches generated by server redirects (but documents don't see them)
• the previous point means that e.forwardTo() will generate a new onfetch in the SW, because the response will be sent to the document which will issue a new request to the SW
• fetches sent by the SW (e.g., via fetch()) which generate redirects do not re-enter the SW. Conceptually, if there was an SW "below" the one in question, it would then get 2 bites at the apple

There's a relativity principle of redirects: each context can't see the redirects, but the layer "behind" it can.

[slightlyoff]

We've had quite a lot more discussion in the last hour and have come to a different conclusion:

• a redirect from the SW (either e.forwardTo() or a 3xx Response) DOES issue a new onfetch to the SW
• any time you go to the network layer, redirects are transparently followed. That implies that fetch() calls and server-sent redirects do not re-enter the SW as new onfetch events.

The motivator here is an xss-amplification due to HTTP-only cookie handling and capability URL leakage. The new resolution preserves the security properties of current browser behavior.

[annevk]

See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=24375

[KenjiBaheux]

Assuming this is either superseded by or a duplicate of #412

[annevk]

No it's not a duplicate. 304 is not a redirect...

[annevk]

Handling redirects is completely spelled out in the specification I think. They are followed.

[KenjiBaheux]

Tracked at crbug.com/402389 for Blink.