4 ms·

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 sta

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 2y ago
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 https://cloud.google.com/storage/docs/batch#http
- tasn 2y ago
  Same problem as using headers. That too is in-band, because the client can also create multipart requests.
  - kccqzy 2y ago
    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 2y ago
      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 2y ago
        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.
  - merb 2y ago
    It would work if all requests would be wrapped
fulafel 2y ago
This is something like it, though no finished standard exists: https://en.wikipedia.org/wiki/HAR_%28file_format%29 https://en.wikipedia.org/wiki/HAR_%28file_format%29 (An abandoned spec is at https://w3c.github.io/web-performance/specs/HAR/Overview.html https://w3c.github.io/web-performance/specs/HAR/Overview.htm...)
cle 2y ago
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.)

kccqzy 2y ago

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 https://cloud.google.com/storage/docs/batch#http

tasn 2y ago
Same problem as using headers. That too is in-band, because the client can also create multipart requests.
- kccqzy 2y ago
  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 2y ago
    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 2y ago
      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.
- merb 2y ago
  It would work if all requests would be wrapped

fulafel 2y ago

This is something like it, though no finished standard exists: https://en.wikipedia.org/wiki/HAR_%28file_format%29 https://en.wikipedia.org/wiki/HAR_%28file_format%29 (An abandoned spec is at https://w3c.github.io/web-performance/specs/HAR/Overview.html https://w3c.github.io/web-performance/specs/HAR/Overview.htm...)

cle 2y ago

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.)