W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-08.txt]

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 02 Aug 2007 12:32:15 +0200
Message-ID: <46B1B2AF.8040105@gmx.de>
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.


> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:31 UTC