Re: Request Speculation (Response Prediction)

While it’s good to find ways to reduce round trips, this approach wouldn’t work in HTTP/2 and HTTP/3 without drastic changes to these protocols, since responses are expected to be sent on respective client-initiated streams. It also wouldn’t work with HTTP/1 if pipelining is enabled, or if the client has multiple requests lined up and simply decides to send another unrelated request first. Not to mention features like path-scoped cookies that might affect the final request.

Redirection is a collaborative process between the client and the server. The client is given the choice to take the redirect, modify the redirect to somewhere different, or not take it at all. If these abilities are taken away, this mechanism is no longer compatible with existing redirection flows. I would suggest using alternative approaches to signal the canonical location without redirects.

Guoye

> On Aug 14, 2023, at 09:32, Soni L. <fakedme+http@gmail.com> wrote:
> 
> Let's say your server is sending a redirect to another page on the same server
> 
> GET /whatever HTTP/1.1
> ...
> 
> 302 Found
> Location: /something
> 
> 
> Instead of waiting for the client to send the follow-up request, why not just send it straight away?
> 
> 302 Found
> Location: /actually
> 
> 
> 200 OK
> ...
> 
> This is different from server push in that it relies on making assumptions about how the client behaves, and it works with HTTP/1.1 too. The User-Agent header and some other fingerprinting techniques might be necessary for sending the right thing tho.
>