상대 위치 헤더를 사용하는 결과는 무엇입니까?


17

사양 에 따르면 리디렉션에 사용되는 위치 헤더 에는 서버 이름이 필요 합니다.

HTTP/1.1 301 Moved Permanently
...
Location: http://example.com/foo/baz/bar

그러나 2012 년에 대부분의 웹 브라우저는 상대 경로를 인식하고 원래 서버 이름을 사용하여 새 위치로 리디렉션합니다.

HTTP/1.1 301 Moved Permanently
...
Location: /foo/baz/bar

Location 헤더에서 상대 URL을 사용하면 부정적인 / 놀랄만 한 결과가 있습니까? 저의 특별한 관심은 Google / 검색 엔진이이를 어떻게 해석 할 것인가에 대한 것이지만, 다른 생각이 있다면 나는 그것을 듣고 싶습니다.


해당 요구 사항을 정확히 파악할 수 있습니까? 도전하지 않고, 나는 그것을 즉시 보지 않고 그것을 찾기 위해 전체 RFC를 읽는 것처럼 느끼지 않습니다. 또한 HTTP 1.0 사양을 인용하고 있지만 예제에서 HTTP 1.1 헤더를 사용하고 있습니다. (허용 된 내용을 변경하거나 변경하지 않을 수 있습니다.)
Su '

10.11 섹션. tools.ietf.org/html/rfc1945#page-44 1.1 사양에는 이것을 "수정"하는 내용도 없습니다.
Alan Storm

답변:


15

HTTP / 1.1 표준의 현재 버전 인 RFC 2616에 따르면 Location헤더 값은 절대 URI 여야합니다 .

그러나 HTTPbis Working Group 이 RFC 2616을 대체하기 위해 준비한 표준 초안 에서는 다음과 같은 이유로 상대 URI도 허용하도록 변경되었습니다 .

"RFC 2616에서 Location 헤더의 정의는 웹상의 컨텐츠와 상호 운용하기 위해 최소한 웹 브라우저가 웹 브라우저를 처리해야하는 방법에있어서 여러 가지 차이점이 있습니다."

실제로 AFAIK는 거의 모든 주요 브라우저와 검색 엔진이 상대 URL 로의 HTTP 리디렉션을 이해하고 받아들입니다. 그러나 언젠가 HTTPbis 초안이 공식 표준이되어 널리 채택 될 때까지 현재 표준을 문자로 구현하고 절대 URL 만 허용하는 새롭거나 모호한 사용자 에이전트가 항상 있습니다. 따라서 현재 안전한 작업은 Postel의 법칙에서Location 제안한 것처럼 헤더에 절대 URL 만 사용하는 것입니다 .

"보내는 것에서 보수적이고, 받아들이는 것에서 자유 로워 라."


3
RFC 2616은 이제 7231에 의해 폐기되었으며 위치 헤더에서 상대 URL을 허용합니다. 편지에 표준을 구현하는 사용자 에이전트는 이제 상대 URL을 허용합니다.
ZoFreX

6

HTTP 1.1 RFC http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 의 14.30 절 은 크게 다르지 않습니다. 나는 당신이 이것에 대한 실제적인 한계를 볼 것이라는 것을 모른다.

내가 Lynx에서 테스트하는 데 사용했을 때이 문제에 대한 경고조차 볼 수있는 유일한 시간은 위치가 절대적이지 않은 경우 "위치 값이 절대적이지 않다"는 경고를 표시합니다. 새로운 위치로. 방금 Lynx 2.8.7을 테스트했으며 구성 문제 일 수는 있지만 더 이상 그렇게하지 않는 것으로 보입니다.

자, 당신은 말합니다 :

저의 특별한 관심은 Google / 검색 엔진이이를 어떻게 해석 할 것인가에 대한 것이지만, 다른 생각이 있다면 나는 그것을 듣고 싶습니다.

나는 이것이 시험을 보증한다고 믿는다. URL을 설정하고 사이트의 xml sitemap 에 넣고 URL을 설명대로 리디렉션하십시오. 해야 할 일은 Google 웹 마스터 도구를 사용하여 확인하고 부정적인 결과 가 있는지 확인하는 것 입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.