Re: HTTP Status 308 (Permanent Redirect)

* Julian Reschke wrote:
>When it was written, the status code description was consistent with the 
>HTTPbis P2 draft that was current back then -- see 
><http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.7.3>.
>
>Since then, the definition was rephrased quite a bit, and I believe it 
>would be good to update the prose in the 308 definition accordingly in 
>order to avoid confusion.

(Accordingly, some of my comments also apply to P2.)

>> 3.  308 Permanent Redirect
>>
>>    The 308 (Permanent Redirect) status code indicates that the target
>>    resource has been assigned a new permanent URI and any future
>>    references to this resource ought to use one of the enclosed URIs.
>>    Clients with link editing capabilities ought to automatically re-link
>>    references to the effective request URI (Section 5.5 of
>>    [draft-ietf-httpbis-p1-messaging]) to one or more of the new
>>    references sent by the server, where possible.

I think the use of "enclosed" here is confusing. Status codes to not en-
close URIs. Response bodies might, but it is unclear whether clients can
use URIs from bodies as intended by the status code. There also cannot
be multiple `Location` headers or multiple URIs in one `Location` header
so it's not immediately clear why this uses the plural.

>>    The server SHOULD generate a Location header field
>>    ([draft-ietf-httpbis-p2-semantics], Section 7.1.2) in the response
>>    containing a preferred URI reference for the new permanent URI.  The
>>    user agent MAY use the Location field value for automatic
>>    redirection.  The server's response payload usually contains a short
>>    hypertext note with a hyperlink to the new URI(s).

I think "a preferred URI reference for" is confusing and redundant and
should be removed (for instance, having multiple preferred URI refs for
an URI would be strange). I have some doubts about the "usually" above
and prefer the previous formulation ("can").

>>    A 308 response is cacheable by default; i.e., unless otherwise
>>    indicated by the method definition or explicit cache controls (see
>>    [draft-ietf-httpbis-p6-cache], Section 4.2.2).

It is not clear to me that this is the same as saying caches may use
a heuristic to determine freshness (that was in the old text). "by
default; i.e.," is redundant and confusing and should be removed.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 6 February 2014 14:43:08 UTC