- From: Scott Perham <scott@polystream.com>
- Date: Thu, 23 May 2019 21:30:33 +0100
- To: Daniel Stenberg <daniel@haxx.se>
- Cc: Scott Morgan <scott@adligo.com>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
The draft definitely needs fleshing out, this shall be done as soon as I can. The header would be sent by the client of a service (not a browser natively or automatically, for example) and only for those services that require it (as usually defined in a service API documentation and as it does today, but for arbitrary headers). For any request that originates from the service as a direct result of the original request and _before the response is returned from the service_ the implementers of that service can include the same header value in the subsequent requests. This would be repeated with a new (random) value on each request sent from the client to that service. This allows the implementers to trace the activity through subsequent service calls. As I said, this is a pattern used by a great many API implementers and is very common practice in RESTful service development, but there is no standardised mechanism for doing so, therefore each service defines their requirements for the header name and value independently. The value of the header is not used in anyway to correlate future or past requests from the client and is typically only persisted by service implementers by way of logging. This differs from cookies in that it is not a mechanism for persisting state across requests, but a mechanism for attaching very specific, ephemeral metadata to individual requests. Thanks, Scott > On 23 May 2019, at 21:10, Daniel Stenberg <daniel@haxx.se> wrote: > >> On Thu, 23 May 2019, Scott Perham wrote: >> >> The primary purpose is to propose a standardised mechanism for API implementers to use as a request flows through potentially a number of services (which often include third-parties that also ask for some form of activity identifier). > > The spec is also not very clear on exactly for what server/origins the client should send this proposed header to. Above here you seem to imply that it could be to more servers than the origin that sent the first response header? And for how long? Forever? > > I'll join the choir: this sounds like cookies - with more holes in the spec. > > -- > > / daniel.haxx.se
Received on Thursday, 23 May 2019 20:31:01 UTC