The server in the HTTP PeerId Auth scheme defines an opaque bearer token that the client should include in every request. It's common to encode an expiry date in the token so that the server can expire tokens after a set amount of time.

When this is the case the client doesn't know when the token will expire, so it needs to handle fetching a new token if the current one starts causing 401s.

This is fine for GET/HEAD/OPTIONS/DELETE requests but when sending request bodies, the body will be consumed by the request that causes the 401 and the user will have to recreate the body to use in a subsequent request with an updated token. Easy if it's a string, less so if it's a stream.

The browser fetch API also doesn't let us read any part of the response until the complete request has been sent so we can't just send the request headers and then read the response headers before deciding whether or not to continue sending data.

A workaround for this is to send an OPTIONS preflight-style request for every POST/PUT/etc request but this increases the amount of requests that need to be made, and it introduces a race condition whereby the OPTIONS request might succeed but the following POST fails due to the token expiring between the two requests.

How about including an additional expires key in the Authentication-Info header that contains the bearer token?

Then the client can step through the authentication process some arbitrary time before their current token expires.

cc @MarcoPolo