Re: REST: ETag handling

On Fri, Mar 22, 2019 at 03:05:20PM -0400, John P. Rouillard wrote:
> >will fail because the resulting value includes quotes. The @etag value
> >in the json representation does *not* include quotes.
> 
> Maybe it should be: { "@etag": ""etagvalue"", ... } I am not sure how to
> encode " inside a json value but you get the idea.
I'd leave the encoding to the json serializer. So just add the quotes to
the string like you do in the header.

> 
> >I think the quotes should be removed in the header, too.
> 
> I thought the quotes in the header were required by spec.
> See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag

Thanks.
This also says that in the request we should send an 'If-Match' header
not an ETag.

> >Another question regarding ETag: The 'PUT' method is supposed to be
> >idempotent. Requiring an ETag kills this property: A second equivalent
> >PUT request where the change is already applied will fail because the
> >ETag doesn't match. Shouldn't we optionally allow a PUT without an ETag
> >and document that using an ETag will make the method non-idempotent?
> 
> Well we can't remove etag as that is required to avoid clobbering an
> update.  Consider the following:
> 
>   app1 gets issue/27
>   app2 gets issue/27
>   app2 changes status to open from new
>   app2 puts change
>   app1 changes status to close from new
>   app1 puts change

I know and understand this. But sometimes a client may want to make sure
it got the last update and wins. So sending the If-Match header should
probably made optional.

> Regarding idempotentcy. I read that as: if the preconditions of the put
> are met, multiple applications of the same PUT data should not change
> the state of the resource.

Wikipedia say otherwise: "whereby they can be applied multiple times
without changing the result beyond the initial application."
https://en.wikipedia.org/wiki/Idempotence
This doesn't apply in this case because after first applying it once the
ETag will change because the PUT modified the data.

> Does this make sense?
I'd change it as follows:
- Change incoming check for ETag to check for If-Match
- Check that the incoming If-Match matches the outgoing ETag *WITH
  QUOTES*: The quotes should be there in both cases. So I can still use
  my naive client implementation as the If-Match header also includes
  quotes.
  So I'd change the etag computation function to include the quotes and
  not apply the quotes in several cases and not in others. Point to the
  spec in the documentation of the ETag computation.
- Make the check optional, so if no If-Match header is found apply the
  change unconditionally.
- Point to this in the documentation and suggest an ETag is always used.

But I'm not religious about that, so if you think that an If-Match
header should always be present, I'm fine.

I can provide a patch if you like.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]