Open GoogleCodeExporter opened 9 years ago
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
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
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
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
Original issue reported on code.google.com by
filip.na...@gmail.com
on 5 Aug 2008 at 5:17