The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)
draft-ietf-httpbis-rfc7238bis-03
Yes
(Adrian Farrel)
(Barry Leiba)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Stephen Farrell)
Abstain
Note: This ballot was opened for revision 02 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -02)
Unknown
Barry Leiba Former IESG member
Yes
Yes
(for -02)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
()
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -02)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -02)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -02)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
()
Unknown
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2015-02-04 for -02)
Unknown
Thanks for addressing my prior discuss with some text in the security considerations section to explain the following is possible without TLS: Couldn't an attacker substitute the URI that the user gets permanently redirected to a malicious site or a competitor, etc.? The security considerations of RFC7231 are pretty thorough, but I didn't see mention of using TLS to prevent session interception for this type of attack or for the privacy protection section.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -02)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -02)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2015-02-04 for -02)
Unknown
Thanks for working through Ted's comments. I shared them.
Stephen Farrell Former IESG member
No Objection
No Objection
(for -02)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(2015-02-03 for -02)
Unknown
I found the text below a bit confusing:
Note: This status code is similar to 301 (Moved Permanently)
([RFC7231], Section 6.4.2), except that it does not allow changing
the request method from POST to GET.
The issue is that if you permanently cache this redirect, then there is no request, and hence no request method to change. I think that what you mean is that if the request that produced the 308 result was a POST, then the redirect is only valid for future POSTs, and if it was a GET, it's only valid for future GETs. I'm fairly confident this is what you intended to say, and the text as is could be read that way, but it might be better expressed this way:
Note: This status code is similar to 301 (Moved Permanently)
([RFC7231], Section 6.4.2), except that it applies only to future
requests with the same method. For example, if the 308 status
code is received in response to a request with a method of
GET, then the redirect only applies to future requests that
also have a method of GET.
This also possibly addresses my other probably naive question, which is whether this applies to request methods other than GET and POST.
Richard Barnes Former IESG member
Abstain
Abstain
(2015-02-04 for -02)
Unknown
"This specification contains no technical changes from the experimental RFC 7238, which it obsoletes." Then why are we wasting time with a new document?