[andrewaylett]

Unfortunately, in-band signalling seems to be the norm when dealing with HTTP. There isn't really a standard mechanism for wrapping up an HTTP request in a standard format and delivering it, plus some trusted metadata, over HTTP to another service.

Or if there is, and I've somehow missed it, please *please* share it with me.

[kccqzy]

Just use MIME multipart content-type to wrap an HTTP message inside another. This is commonly done for batching requests. Here is an example of how it might look like: https://cloud.google.com/storage/docs/batch#http

[tasn]

Same problem as using headers. That too is in-band, because the client can also create multipart requests.

[merb]

It would work if all requests would be wrapped

[kccqzy]

That misses the point. The OP's original use case is for a middleware to wrap a client request. The middleware would reject such multipart requests from the client.

[tasn]

The same way that it can reject certain headers, like it could have done in this case. It's no different, still in-band.

[kccqzy]

The middleware doesn't have to reject it. It could decide to just wrap it and pass it along. The backend code can then be able to distinguish which was sent by the client and which was added by the middleware. And that's the point. The middleware can do as little or as much filtering it desires, without causing any confusion to the backend.

[cle]

The absurd part to me is that this is all internal to the framework, why on earth does NextJS need to wrap up an HTTP request and re-send it...to itself...?

(I think the answer is because of the "requirement" that middleware be run out-of-process as Vercel edge functions.)

[fulafel]

This is something like it, though no finished standard exists: https://en.wikipedia.org/wiki/HAR_%28file_format%29

(An abandoned spec is at https://w3c.github.io/web-performance/specs/HAR/Overview.htm...)