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

Re: New "200 OK" status codes, PATCH & PROPFIND

From: Adrien de Croy <adrien@qbik.com>
Date: Tue, 07 Aug 2007 09:36:37 +1200
Message-ID: <46B79465.2060504@qbik.com>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>


I'm probably going to get shot down for this but... just an observation

All these extensions to the core protocol to deal with relatively 
minority cases seems problematic to me.

Modifications to the protocol require adoption by all parties in any 
comms.  There's a lot of infrastructure out there that won't change: 
proxies, servers... clients.

Add to that the proposed complexity of "Preferences" vs "Expectations".  
The problem with preferences is they are non-deterministic.  Just like 
in real life (i.e. with people) :)

So, my suggestion would be to layer something over the top of HTTP for 
use-cases like this.  Use SOAP or something, and define the XML that 
goes back and forth to do this editing and patching as a separate spec, 
but leave HTTP alone.  Then modifications to the requirements for the 
special situations are independent of the transport protocol.

imagine if we extended TCP whenever we wanted some new application-level 
functionality?

Regards

Adrien


Julian Reschke wrote:
>
> Henrik Nordstrom wrote:
>> ...
>> 210 Information returned
>> to be used when auxillary information about the requested entity or
>> resource is returned. This response do not invalidate any cached
>> entities for the URI. The response may contain a Content-Location
>> indicating an URI where the same information can be retreived using GET
>> and optionally an Content-ETag header providing the current ETag for the
>> same.
>>
>> ...
>>
>> Example use case for "210 Information Returned" is PROPFIND
>
> The problem with 210 (instead of 207) is that you can't deploy it. 
> Clients expect 207. So either we'd need to expand the semantics to 
> 207, or clients would need to be able to signal they understand 210.
>
> It seems that you're trying to mirror the GET-Location header 
> functionality into status codes and existing headers, with which I 
> sympathize.
>
> But wouldn't we also need some mechanism for the validity time, see 
> "max-age" in 
> <http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html#rfc.section.3>? 
>
>
> Best regards, Julian
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Monday, 6 August 2007 21:36:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:15 GMT