Return weak ETags on PUT

[GoogleCodeExporter]

It would certainly be nice to return ETag header with weak entity tag on
successful PUT request if the stored calendar object is semantically
equivalent to the submitted text/calendar resource. It would save one
roundtrip for a client and regetting of the just uploaded data.

Original issue reported on code.google.com by filip.na...@gmail.com on 5 Aug 2008 at 5:17

[GoogleCodeExporter]

This has similiar interoperability issues like Issue 12. Technically the ETag 
in the
PUT response belongs to the PUT response entity, its an entity header. Its not 
very
clearly specified in HTTP and I know that some interpret it this way or the 
other.

Note: _Personally_ I do agree that returning a (strong) ETag representing the
resource after the PUT is a good idea.

I don't see how returning a _weak_ ETag will help you since weak ETags are not
allowed in if-match/if-none-match headers.

Original comment by helge.h...@googlemail.com on 5 Aug 2008 at 5:59

[GoogleCodeExporter]

Just for reference, there was a draft that tried to cleanup the ETag confusion, 
but
personally it made me even more confused:
http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-latest.html

Weak ETag ARE allowed in if-match/if-none-match, but only for HEAD/GET.

Even weak ETags are valid for some synchronization purposes and that's also why 
Cosmo
CalDAV uses them. I think it's perfectly valid to do PUT and then HEAD with the 
weak
ETag in If-Match to get the the strong ETag without actually downloading the 
body.
(Ok, I just made that up, but I may actually implement it in our client.) As 
long as
no octet equality is required I believe it's possible to use weak ETags for
synchronization.

Original comment by filip.na...@gmail.com on 5 Aug 2008 at 6:15

[GoogleCodeExporter]

Hm, always good to read the spec of *both* headers :-) Apparently you read
If-None-Match, which allows weak ETags for GET/HEAD, while I read If-Match, 
which
explicitly requires strong validation :-)

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Anyways, this wasn't my initial point. The source of confusion is what the ETag 
in
the PUT response refers too. There is no agreement on that, hence interop 
issues.
Unfortunately.

Original comment by helge.h...@googlemail.com on 5 Aug 2008 at 6:33

[GoogleCodeExporter]

I still believe it's allowed to use If-Match with weak ETag in GET/HEAD 
according to
the original RFC2616, section 13.3.3 - "Clients MAY issue simple (non-subrange) 
GET
requests with either weak validators or strong validators. Clients MUST NOT use 
weak
validators in other forms of request.". In any case the restriction has been 
lifted
from the upcomming HTTP specification and now weak ETags are allowed even in 
PUT:
http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p4-conditional-03.txt 
(see
appendix A).

Anyway, my original point was that the server should return ETag on PUT if at 
all
possible. I don't really care if it's ETag+Entity-Transform (per
http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-latest.html) 
or
weak ETag (in the HTTPbis definition of it).

Original comment by filip.na...@gmail.com on 6 Aug 2008 at 7:53