Handling of ETags (in RedisStorage) weird

[oli-h]

Preface

vertx-rest-storage generates an ETag value when you PUT a resource to Redis. Example:

$ curl -X PUT -d "{}" http://localhost:7013/houston/etag-test

then you find in Redis:

127.0.0.1:6389> keys *etag-test*
1) "rest-storage:resources:houston:etag-test"
127.0.0.1:6389> hgetall "rest-storage:resources:houston:etag-test"
1) "resource"
2) "{}"
3) "etag"
4) "1be0de90-01f4-4b57-b160-4ed8729f9ec3"

Note: This generated ETag is a random UUID. When you repeat the PUT (with same URL and same body", a new UUID is generated - so the ETag is not a body hash or so.

When you later GET this resource, the ETag is reported as http-Header:

$ curl -v http://localhost:7013/houston/etag-test
[...]
< HTTP/1.1 200 OK
< Etag: 1be0de90-01f4-4b57-b160-4ed8729f9ec3
< Content-Type: application/json; charset=utf-8
< content-length: 2
<
{}

When you get with request header 'if-none-match', then rest-storage optimizes the response as "304 not modified":

$ curl -v -H "if-none-match: 1be0de90-01f4-4b57-b160-4ed8729f9ec3" http://localhost:7013/houston/etag-test
[...]
< HTTP/1.1 304 Not Modified
< Etag: 1be0de90-01f4-4b57-b160-4ed8729f9ec3
< content-length: 0

so far, so good

Weird 1

When you PUT a new resource, then you can hand over an ETag as http request header, avoiding the generation of a random UUID - with the header "if-none-match". Example:

$ curl -v -X PUT -d "{}" -H "if-none-match: gaga" http://localhost:7013/houston/etag-test2

$ curl -v http://localhost:7013/houston/etag-test2
[...]
< HTTP/1.1 200 OK
< Etag: gaga
< Content-Type: application/json; charset=utf-8
< content-length: 2
<
{}

127.0.0.1:6389> hgetall "rest-storage:resources:houston:etag-test2"
1) "resource"
2) "{}"
3) "etag"
4) "gaga"

I think the request header "if-none-match" should never influence the ETag value. Either we should completly disable the option to give an explicit ETag value on PUT or we use "ETag" as request header to give the ETag value (and not "if-none-match") - although "ETag" is only specified to be a response-header.

Weird 2

generated ETag value should better be a hash of the content than a random UUID. This makes the ETag stronger, leading to a constant ETag value if a resource with same body is PUT multiple times.

Weird 3

There is no "if-match" handling - but this would be valuable especially for PUT requests.
We could youe it for optimistic locking for resources, able to find modified resources by some other clients before we PUT a changed version of a resource.