Subject: HTTP Status 308 (Permanent Redirect)

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Feb 2014 13:28:40 +0100

Hi there,

this status code was defined in draft-reschke-http-status-308-07 and 
approved as Experimental RFC almost two years ago:

   <https://datatracker.ietf.org/doc/draft-reschke-http-status-308/>

It's been sitting in the RFC Editor queue since then, waiting for the 
HTTPbis specs to arrive.

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.

The proposed diffs are here: 
<http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-latest-from-previous.diff.html> 
(which also contains some more changes due to HTTPbis P2 section number 
changes).

The full text of the section would change from:

> 3.  308 Permanent Redirect
>
>    The target resource has been assigned a new permanent URI and any
>    future references to this resource SHOULD use one of the returned
>    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 returned by the server, where possible.
>
>    Caches MAY use a heuristic (see [draft-ietf-httpbis-p6-cache],
>    Section 2.3.1.1) to determine freshness for 308 responses.
>
>    The new permanent URI SHOULD be given by the Location field in the
>    response ([draft-ietf-httpbis-p2-semantics], Section 10.5).  A
>    response payload can contain a short hypertext note with a hyperlink
>    to the new URI(s).
>
>       Note: This status code is similar to 301 Moved Permanently
>       (Section 7.3.2 of [draft-ietf-httpbis-p2-semantics]), except that
>       it does not allow rewriting the request method from POST to GET.

to:

> 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.
>
>    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).
>
>    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).
>
>       Note: This status code is similar to 301 (Moved Permanently)
>       ([draft-ietf-httpbis-p2-semantics], Section 6.4.2), except that it
>       does not allow changing the request method from POST to GET.

Although this hasn't been a WG work item, it would be awesome if a few 
people could review the proposed change and give feedback about whether 
this would be an acceptable change prior to publication as RFC.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 06 Feb 2014 15:42:41 +0100

>order to avoid confusion.

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

>>    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.

>>    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").

>>    [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:[email-masked] · 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/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Feb 2014 15:50:51 +0100

On 2014-02-06 15:42, Bjoern Hoehrmann wrote:
> ...

Actually, all of them.

P2 is past WG LCs, IETF LCs, and IESG review, so I'd prefer not to make 
any changes at this point of time.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Feb 2014 12:12:13 +1100

LGTM.

On 6 Feb 2014, at 11:28 pm, Julian Reschke <[email-masked]> wrote:

> Hi there,
> 
> this status code was defined in draft-reschke-http-status-308-07 and approved as Experimental RFC almost two years ago:
> 
> It's been sitting in the RFC Editor queue since then, waiting for the HTTPbis specs to arrive.
> 
> 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.
> 
> The proposed diffs are here: <http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-latest-from-previous.diff.html> (which also contains some more changes due to HTTPbis P2 section number changes).
> 
> Although this hasn't been a WG work item, it would be awesome if a few people could review the proposed change and give feedback about whether this would be an acceptable change prior to publication as RFC.
> 
> Best regards, Julian
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Feb 2014 08:57:49 +0100

> LGTM.

OK.

So can we do this during AUTH48, or should I submit a new draft?

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Thu, 13 Feb 2014 21:59:35 -0500

> So can we do this during AUTH48, or should I submit a new draft?

If the WG is OK with it, we'll do it during AUTH48.

b

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Feb 2014 14:29:21 +1100

> If the WG is OK with it, we'll do it during AUTH48.

Anyone have an issue with this?