- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 02 Aug 2007 12:32:15 +0200
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- CC: "Roy T. Fielding" <fielding@gbiv.com>, Mark Baker <distobj@acm.org>, Lisa Dusseault <lisa@osafoundation.org>, ietf-http-wg@w3.org
Stefan Eissing wrote: > Since we are defining anyway, I am wondering how this works with clients > that are not interested in such a response body. The only way they could > avoid retrieving the body is to close connection. Right. Not good. It seems to me that this tries to optimize the uncommon case. What's the problem with refetching the content in a second request if you really need it? > I imagine as use case clients that edit/add ID tags on a web resource > and perform a binary patch. Most certainly that will be protected by > ETags and the client will not be interested in retrieving the quite > large representation again. Yes. > Is it worth considering a way for him to say so, or is closing the > connection the appropriate behaviour? Imagine someone like flickr... > > It sounds like a nice job for a new "Expect" request header. Let's say > we call this "patched-content": > > PATCH /resource/x HTTP/1.1 > Host: www.example.com > Expect: patched-content > Content-Type: ... > > HTTP/1.1 417 Expectation failed > ... > <html><body>Sorry, we do not server content on a patch.</body></html> > ... This has as deployment problem: "Expect" is hop-by-hop, so it won't work with intermediates that do not now about it. Best regards, Julian
Received on Thursday, 2 August 2007 10:32:30 UTC