should there be a permanent variant of 307

[julian.reschke@…]

301 can not be used reliably for permanent redirects that leave the method alone.

Should there be a variant of 307 that implies permanence? If not, should we describe how to *make* it permanent using caching directives?

[mnot@…]

Minting a new status code is out-of-charter for us (but of course can be done in an independent draft, and we could incorporate it into draft-nottingham-http-new-status).

IIRC we've discusssed "permanent' cache-control before, and the consensus was that there's little value in defining new directives to do so, and techniques for doing it with existing directives are well-known.

So, closing this as wont fix; if I missed something, please reopen.

[julian.reschke@…]

I think the summary is correct; but there's still a TODO.

Either we should decide that defining a new status somewhere else makes sense; that depends a bit on whether a new code is deployable (which it probably is not).

Otherwise, we should add some language to P2 *demonstrating* how to do this instead of ignoring the issue.

[julian.reschke@…]

Proposed patch

[julian.reschke@…]

From [1474]:

Note that there is no permanent variant of 307 (see #312)

[julian.reschke@…]

From [1475]:

Rephrase so it's clear that other specs might do that in the future (see #312)

[julian.reschke@…]

From [1505]:

remove now unneeded reference to ticker 312 (permanent variant of 307) (see #312)

[julian.reschke@…]

​https://datatracker.ietf.org/doc/draft-reschke-http-status-308/ is in IETF Last Call, ending 2012-03-16.

Should it get approved we should change the note added in [1474] and [1475] to point to that spec.

[julian.reschke@…]

Spec approved; see ​https://datatracker.ietf.org/doc/draft-reschke-http-status-308/

[julian.reschke@…]

Proposed patch (pointing at status code 308)

[julian.reschke@…]

From [1614]:

Note existence of status 308 (see #312)