![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
On Jun 15, 2006, at 9:32 AM, Wilfredo Sánchez Vega wrote:
I agree with Julian.
As we've mentioned before, Apache returns a weak ETag on PUT, which turns into a strong ETag sometime later. If clients rely on being able to use that ETag on a GET later, they won't work with Apache, and IIRC, Apache is pretty popular.
The ETag requirements in the draft are what many clients authors might *like* to be the common case, but it is most certainly not so today.
It's worse than that; many client authors *assumed* that to be the case, and implemented and deployed their clients assuming that if the client receives a strong ETag in response to a PUT, it has no further work to do to synchronize that resource. So the deployed base says that *is* the case today. I don't feel our document makes this situation any worse than the deployed base of clients already does.
Lisa
Best regards, Julian
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.