Support for Etag/If-Match/If-None-Match

[uepoch]

Is your feature request related to a problem? Please describe. We would like to implement RFC-7232 for some of our backends and most notably the ETag/If-Match/If-None-Match standard This would allow clients to leverage on this to reduce the number of requests actually processed by the barrier and improve number of requests handled by a vault cluster at a time (provided you are using the OSS version)

Describe the solution you'd like The simplest way we though of was to add a Header field in the logical.Response returned by the backend, that allow backends to return headers directly to the client Theses would get added to the http response by the request handler

Describe alternatives you've considered For this specific use-case (Etag family), this might have sense to implement it directly in the core request handling, for paths that are indempotent on read/write/delete operations Whether to enable it or not could be declared by the logical.Path entries Last modifying request ID could be used as a 128bit key (with the first read id, if none is present) Theses could be flushed as non-secret on storage

Explain any additional use-cases Adding support for response headers would some interesting auth mechanisms such as SPNEGO which rely on a multi-step handshake between server and client with http header Adding generic support for etag would be a nice feature that could benefit other backends with few additional cost

[jefferai]

SPNEGO is already going to be supported in 1.0.3, see https://github.com/hashicorp/vault/pull/6115

[uepoch]

Great news :)

[uepoch]

Hello, Nice to see allowed_response_headers is now a thing !

WDYT about implementing ETag family header more generally at logical.Backend level ?

Here's a starting proposition (probably with some flaws):

This could be done at routeCommon level once you get the RouteEntry containing the backend configuration

The logical backends could expose cacheable prefixes as a SpecialPaths type Then, add the possibility to declare a custom hash function declared in the logical.Backend interface for path prefixes (map<path, hashfunc>) or default to use the 128 bit request-id as the hash key

This could get disabled along with the regular physicalCache and could be stored physically or only in-memory. Not sure if it's worth saving on physical, but I don't know all the usages..

This way, you could reduce both the number of hits in the cost-y decrypt/encrypt processes and lists, while keeping a tiny memory overhead (let's say an average 40 ascii chars path, for 10k entries would take (40*8 + 128) * 10000 =~ 4,4Mbit if using a plain old map, forgetting about smaller allocs)

Would this looks okay to you ?

[aphorise]

What is the status on this request? - is support for this already provided or expected to be further coming anytime in the future?

[aphorise]

This would have overheads in terms having to compute the Etag - also needing additional memory discarding update logics as well as having do read user provided Etag on request.

@uepoch I'm curious how relevant is this request for you still?

[hsimon-hashicorp]

Due to the issue age and quiescence, I'm going to go ahead and close it now. Please feel free to re-open as needed!