Re: Request Speculation (Response Prediction)

On 2023-08-14 20:20, Matthew Kerwin wrote:
> On Tue, 15 Aug 2023 at 02:33, Soni L. <fakedme+http@gmail.com> wrote:
> >
> >
> > 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.
> >
>
> Is this already achievable with a link relation? It feels similar to
> rel=canonical to me.
>
> Cheers

It is not! This is entirely about being lazy. A realistic scenario:

Software used:
- Mastodon instance at sleeping.example
- nginx in front of Mastodon

Desired outcomes (sysadmin side):
- Implement an API at /.well-known/protocol-handler?target={uri}

Mastodon features and design choices:
1. Ability to remotely interact with an URI [effectively a protocol 
handler], at /authorize_interaction?uri={uri}
1.a. Redirects to local URI after fetching the post, e.g. 
/@RemoteUser@remote.example/1234567...9

Sysadmin choice:
1. Redirect from /.well-known/protocol-handler?target={uri} to 
/authorize_interaction?uri={uri} in nginx
1.a. Easier than implementing it in Mastodon, and less likely to break 
due to updates (less maintenance)

Resulting flow, with HTTP/1.1, as seen from client:

1. [0ms] GET /.well-known/protocol-handler?target={uri}
2. [100ms] Location: /authorize_interaction?uri={uri}
3. [110ms] GET /authorize_interaction?uri={uri}
4. [210ms] Location: /@RemoteUser@remote.example/1234567...9
5. [220ms] GET /@RemoteUser@remote.example/1234567...9
6. [420ms] [...]

(step 6 takes longer (+100ms) due to sleeping.example having to query 
remote.example)

Resulting flow, with speculative execution, as seen from client:

1. [0ms] GET /.well-known/protocol-handler?target={uri}
2. [100ms] Location: /authorize_interaction?uri={uri}
3. [101ms] Location: /@RemoteUser@remote.example/1234567...9
4. [110ms] GET /authorize_interaction?uri={uri}
5. [120ms] GET /@RemoteUser@remote.example/1234567...9
6. [202ms][...]

(step 3 is queued up and only processed after client sends out step 4. 
server already starts working on step 6 long before client requests it.)

Received on Monday, 14 August 2023 23:55:50 UTC