Overwriting HTTP 301 responses

Question

I have two pages on a website. Originally /a returned a 301 redirect to /b. I have changed the pages so that /b now returns a 301 redirect to /a (which now has content instead of /b). The behavior I am seeing is that the browser invalidates the 301 from /a to /b and replaces it with the new 301 from /b to /a, thus preventing a redirect loop.

I want to confirm the behavior I'm seeing in current browsers (Chrome, Firefox, IE, and Edge) is understood to be the correct behavior. I've looked at RFC 2616, but it doesn't cover this corner case, as far as I can tell. Can anyone confirm that this is behavior as defined by the spec, or by well established precedent (i.e. browser have been behaving this way for many years)?

For more information, the concrete case I'm working on is a page that actively redirects off of HTTPS onto HTTP. I want to reverse this to force HTTPS. In my case, /a and /b are actually the same page, just accessed via different protocols.

Edit

Section 10.3 of RFC 2616 says:

A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.

I'm guessing this is the guiding principle in the cache-busting behavior I'm seeing. Still not a solid answer on whether the behavior is per-spec, or just the only thing that makes sense.

Edit 2

Another relevant bit from the RFC (Section 13.12)

If a new cacheable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8) response is received from a resource while any existing responses for the same resource are cached, the cache SHOULD use the new response to reply to the current request. It MAY insert it into cache storage and MAY, if it meets all other requirements, use it to respond to any future requests that would previously have caused the old response to be returned. If it inserts the new response into cache storage the rules in section 13.5.3 apply.

It seems that in light of the sections I've posted, that the behavior I'm seeing is what is suggested by the spec, if not completely spelled out.

Care to elaborate? I understand that browsers cache 301s indefinitely. I'm specifically curious about the case where a newer 301 supersedes an old one. — Eric Andres, Jan 17 '17 at 21:40
This seems to be discussed pretty well in the second portion of this answer: http://stackoverflow.com/a/21396547/1072229 — Grisha Levit, Jan 17 '17 at 21:59
@GrishaLevit I saw that part of the answer. Unfortunately there's enough hedging on whether issuing a new 301 actually works that I'm not comfortable with the answer. — Eric Andres, Jan 17 '17 at 23:13
FWIW, RFC 2616 is obsolete. You really need to look at RFC 7231. — Julian Reschke, Jan 18 '17 at 07:06

score 0 · Answer 1 · edited Oct 07 '21 at 13:28

Redirection 3xx section of RFC 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content defines that behaviour. Relevant excerpt:

A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).

Note: An earlier version of this specification recommended a maximum of five redirections ([RFC2068], Section 10.3). Content developers need to be aware that some clients might implement such a fixed limitation.

Overwriting HTTP 301 responses

1 Answers1