- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 21 Oct 2011 15:30:02 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "Thomson, Martin" <Martin.Thomson@commscope.com>, Dan Anderson <dan-anderson@cox.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Oct 19, 2011, at 7:48 PM, Mark Nottingham wrote: > On 20/10/2011, at 9:35 AM, Roy T. Fielding wrote: > >>> I wonder if a 3xx response was considered. Since the typical scenario involves redirection, it's not that much of a stretch to imagine 3xx. >> >> I am not sure if we considered it or not -- it would be nice to make use >> of the Location header field. Mark? > > I think it was discussed a long time ago, in the previous draft. We can't assume that existing clients will treat a 3xx with a Location as a redirect, so it's of limited value (now) to use 3xx. I don't see why that matters -- if they don't redirect, then the content will be displayed (just like 511). > Also, redirection status codes currently all have a semantic of "the thing you're looking for is over there." In this case, that wouldn't be true. I know that's not a codified semantic of 3xx, but it does lead to a one-of-these-things-is-not-like-the-other situation. That wasn't true in the past. I guess it might be now that we removed 305 (and ignored 306). 3xx was defined as "The client must take additional action to complete the request." > And, of course, we can always specify the use of Location on 511 (for what good it will do). Not much. The advantage of 511 could be that an authentication form can be in the 511 content and not require an additional redirect, though I personally prefer the redirect because it allows the browser to use stored credentials or form-filling features to quickly satisfy the portal. OTOH, that does have some security problems of its own. ....Roy
Received on Friday, 21 October 2011 22:30:31 UTC