- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 6 Aug 2007 19:36:40 -0700
- To: James M Snell <jasnell@gmail.com>
- Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
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 Tuesday, 7 August 2007 02:36:55 UTC