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

Well, the good thing is that there is no particular reason to rush this
particular method to standardization.  We definitely need to get some
folks implementing this.  Dependent entirely on how much time I'm able
to etch out, I'm hoping to have a simple implementation of a
PATCH-enabled atompub server available.  With that, I can enable both
approaches (200+Content-Location and the 209 response) and will
hopefully be able to start evaluating them.

That said, the primary rationale behind 209 is not that
200+Content-Location wouldn't work; it's that 200+Content-Location is
somewhat amiguous and error-prone.  If there are ways of resolving those
issues, then great.

- James

Roy T. Fielding wrote:
> On Aug 6, 2007, at 5:34 PM, James M Snell wrote:
>> Or it won't be enough and people still won't use it as specified.  I'm
>> not saying it's a good thing, but a new status code is likely the more
>> reliable of the two options.
> 
> I don't see how we can guess that.  The existing mechanism is already
> deployed, which means no technology changes other than the preexisting
> task of fixing broken configurations.  Content-Location has a lot of
> value outside HTTP (think mail gateways and external archives), so
> there are side benefits to using it correctly.
> 
> After all, there were many good reasons for us choosing this design
> in the first place, and I really don't have any confidence that the
> folks who currently incorrectly implement content-location will have
> any more success correctly implementing a new status code or headers.
> In my opinion, choosing a new status code for 2xx (content in response)
> is no more likely to succeed than 200+Content-Location indicating
> the same for all methods.  I suggest, however, that any additions to
> HTTP need to be proven first by implementations, and it would be very
> annoying to deploy a new status code only to find out later that we
> didn't need it.  Defining new things is a serious brain tax.
> 
> ....Roy
> 
>

Received on Wednesday, 8 August 2007 16:35:30 UTC