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

Re: PATCH Draft

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 26 Jun 2007 03:35:16 +0200
To: Lisa Dusseault <ldusseault@commerce.net>
Cc: James M Snell <jasnell@gmail.com>, ietf-http-wg@w3.org
Message-Id: <1182821716.9741.29.camel@henriknordstrom.net>
mån 2007-06-25 klockan 17:05 -0700 skrev Lisa Dusseault:

> That should be fine.  I wonder if it's worth the extra variation to  
> allow the server to carry the entire modified entry.  In some cases  
> that would remove the whole point of supporting PATCH (allowing  
> authoring of large files without constant uploading and downloading  
> of entire file) so returning the body at least has to be optional.

The draft already talks about returning the modified entity, with an 200
example carrying it..

If the server do not want to return the modified entity then it can
return a 204.

The only question is if there is a need to have the server return status
messages on a successful PATCH other than the entity itself, or the
actual resulting diff if some server-side processing was done. If 200
returns the modified entity then what to use if the server do not want
to return the modified entity but instead need to return status messages
about the successful PATCH operation or perhaps a diff?

For as long as 200 returns the modified entity there is no reason not to
allow it to be cached.

> Accept is a request header.  I assumed that it would be viewed in bad  
> taste to use it as a response header.  It might also in the long run  
> be confusing -- the server might accept certain diff formats for  
> PATCH, but accept other inputs for other purposes.


But a more expressive name than Accept-<method> should probably be used
then. If not there is a risk for a name collision if/when other Accept-X
headers is added or new methods with similar names..

Also I don't see why the server should not be allowed to indicate
preference via the quality parameter.

So I propose using the same production as for Accept, and to name the
header somewhat differently to avoid conflicts later on. Possible


Then there is also the Accept-Charset, Accept-Language and
Accept-Encoding metrics to worry about if trying to make a header scheme
where the server can indicate it's content preferences for specific


Received on Tuesday, 26 June 2007 01:35:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC