웹 사이트에 두 페이지가 있습니다. 원래 /a은 /b으로 301 리디렉션을 반환했습니다. /b이 /a (현재 /b 대신 내용이 있음)으로 301 리디렉션을 반환하도록 페이지를 변경했습니다. 내가보고있는 동작은 브라우저가 /a에서 /b으로 301을 무효화하고 /b에서 으로 새 301을 바꿔 리디렉션 루프를 방지합니다.HTTP 301 응답을 덮어 씁니다.
현재 브라우저 (Chrome, Firefox, IE 및 Edge)에서 나타나는 동작이 올바른 동작으로 인식되고 있는지 확인하고 싶습니다. 나는 RFC 2616을 보았지만, 내가 말할 수있는 한이 코너 케이스는 다루지 않는다. 누구나 이것이 사양에 의해 정의 된 동작인지, 또는 잘 정립 된 선례 (브라우저가 수년간 이런 식으로 행동했는지)를 확인할 수 있습니까?
자세한 내용은 현재 HTTPS를 HTTP로 리디렉션하는 페이지입니다. 나는 이것을 역전 시켜서 HTTPS를 강제하고 싶다. 필자의 경우 /a과 /b은 실제로 동일한 페이지이며 다른 프로토콜을 통해 액세스했습니다.
편집 RFC 2616의
Section 10.3는 말한다 : 같은 루프는 각 재 지정에 대한 네트워크 트래픽을 생성하기 때문에
클라이언트는, 무한 리디렉션 루프를 감지해야한다.
저는 이것이 캐시 - 버스 팅 동작의 기본 원리라고 생각합니다. 그 행동이 스펙에 따른 것인지 아닌지, 아니면 의미가있는 유일한 것인지에 대한 확실한 대답은 아직 없습니다.
은 RFC 또 다른 관련 비트가 새로운 캐시는 응답이 (Section 13.12)
을 (섹션 14.9.2, 13.2.5, 13.2.6 및 13.8 참조) 경우 편집 2
동일한 자원에 대한 기존 응답이 캐싱되는 동안 자원에서 수신 된 경우 캐시는 새로운 응답을 사용하여 현재 요청에 응답해야합니다 (SHOULD). 캐시 저장 장치에 그것을 삽입 할 수 있고 다른 요구 사항을 모두 만족하면 이전 응답을 반환하게 만들었던 앞으로의 요청에 응답 할 수있다. 새로운 응답을 캐시 저장소에 삽입하면 13.5.3 절의 규칙이 적용됩니다.
내가 게시 한 섹션에 비추어 볼 때 내가 본 행동은 스펙에서 제안한 것입니다. 완전히 철자가 맞지 않은 것 같습니다.
정성스럽게 케어 하시겠습니까? 나는 브라우저가 무기한으로 301s를 캐싱한다는 것을 알고 있습니다. 나는 특히 새로운 301이 오래된 것을 대체하는 경우에 대해 궁금합니다. –
아, 죄송합니다. 잘못 읽었습니다. –
이것은이 답변의 두 번째 부분에서 매우 잘 논의 된 것으로 보입니다. http://stackoverflow.com/a/21396547/1072229 –