Location

사용법

서버는 클라이언트를 다른 URL로 안내할 때 Location을 포함시킵니다. 이 헤더는 두 가지 맥락에서 나타납니다. 리다이렉트 응답과 리소스 생성입니다.

리다이렉트에서 Location 값은 다음 요청을 어디로 보낼지 클라이언트에 알려 줍니다. 동작은 상태 코드에 따라 달라집니다.

리소스 생성에서는 201 Created 응답이 새로 생성된 리소스를 가리키는 Location을 포함합니다. 이로써 클라이언트는 별도의 검색 없이 직접적인 참조를 얻습니다.

Location 값은 절대 URL과 상대 URL을 모두 받습니다. 상대 URL은 요청 URI를 기준으로 해석됩니다.

참고

Location 헤더와 Content-Location 헤더는 서로 다른 목적을 가집니다. Location은 리다이렉트 대상이나 새로 생성된 리소스를 가리킵니다. Content-Location은 반환된 표현의 직접적인 URL을 식별합니다.

참고

검색 엔진은 리다이렉트를 따라가며, 영구 리다이렉트(301, 308)에서는 링크 자산(순위 가치)을 대상 URL로 이전합니다. 임시 리다이렉트(302, 307)는 링크 자산을 항상 전달하지는 않습니다. URL 마이그레이션 중에 올바른 상태 코드를 사용하면 검색 순위가 보존됩니다.

URL

값은 대상 위치를 가리키는 단일 URI 참조입니다.

Location: <url>

URL은 스킴과 호스트를 포함한 절대 URI이거나, 요청 URI를 기준으로 해석되는 상대 참조입니다.

예시

옛 도메인에서 새 도메인으로의 영구 리다이렉트는 북마크와 링크를 갱신하라고 클라이언트에 알립니다. 301에서는 클라이언트가 요청 메서드를 POST에서 GET으로 바꿀 수 있습니다.

HTTP/1.1 301 Moved Permanently
Location: https://new.example.re/products

308 영구 리다이렉트는 원래의 요청 메서드를 보존하므로 POST를 비롯한 GET이 아닌 요청에도 안전합니다.

HTTP/1.1 308 Permanent Redirect
Location: https://new.example.re/products

POST 요청으로 리소스를 생성한 뒤, 서버는 새 리소스의 Location과 함께 201을 반환합니다.

HTTP/1.1 201 Created
Location: /api/orders/7891
Content-Type: application/json

폼 제출 이후의 303 응답은 클라이언트를 GET으로 결과 페이지에 리다이렉트합니다.

HTTP/1.1 303 See Other
Location: /search/results?q=http+headers

문제 해결

리다이렉트 실패는 보통 무한 루프, 깨진 URL, 응답에서 빠진 헤더로 나타납니다.

리다이렉트 루프. Location 헤더가 현재 URL을 다시 가리키거나, 되돌아오는 리다이렉트를 하는 또 다른 URL을 가리켜 무한 순환이 만들어집니다. 브라우저는 정해진 횟수의 홉 이후 멈추고 ERR_TOO_MANY_REDIRECTS 오류를 표시합니다. curl -L -v 로 체인을 추적하여 루프를 찾아내십시오. 흔한 원인으로는 서버 규칙이 HTTP를 HTTPS로 리다이렉트하는데 로드 밸런서가 HTTPS를 다시 HTTP로 리다이렉트하는 경우, 또는 nginx의 return 301 규칙이 목적지 URL에도 적용되는 경우가 있습니다. nginx에서는 if ($scheme = http) 가드를 좁게 사용하고 두 프로토콜 모두로 테스트하십시오.

상대 URL이 올바르게 해석되지 않습니다. Location 값은 상대 참조를 받지만, 일부 구형 클라이언트와 중간 노드는 절대 URL을 기대합니다. /new-page 같은 경로는 요청 URI를 기준으로 해석됩니다. 앞의 슬래시를 빠뜨리면 현재 디렉터리를 기준으로 해석되는 상대 경로가 되어 예상치 못한 결과가 나옵니다. 모호함을 피하려면 스킴과 호스트를 포함한 절대 URL을 사용하십시오.

3xx 응답에 Location 헤더가 없습니다. Location 헤더 없는 리다이렉트 상태 코드는 클라이언트에 목적지를 알려 주지 못합니다. 브라우저는 빈 페이지나 오류를 표시합니다. curl -I https://example.re/old-path 로 서버 응답을 확인하고 헤더가 있는지 점검하십시오. Apache에서는 Redirect와 RedirectMatch 디렉티브가 항상 헤더를 포함합니다. 직접 작성한 애플리케이션 코드는 헤더를 명시적으로 설정해야 합니다.

리다이렉트 대상의 프로토콜 불일치. HTTPS 사이트에서 Location 헤더에 HTTP URL이 들어가면 혼합 콘텐츠 경고가 발생하거나 엄격한 환경에서는 리다이렉트가 차단됩니다. 대상 URL이 출발 프로토콜과 일치하거나 HTTPS로 업그레이드되도록 하십시오. nginx에서는 return 301 https://$host$request_uri; 를 사용하여 보안 스킴을 유지하십시오.

리다이렉트를 넘어 프래그먼트가 보존되지 않습니다. 원래 URL의 프래그먼트 식별자(#section)는 Location 헤더로 전달되지 않습니다. 브라우저는 대상 URL에 자체 프래그먼트가 없을 때만 원래 프래그먼트를 리다이렉트 대상에 다시 붙입니다. Location 값에 다른 프래그먼트가 들어 있으면 원래 것은 사라집니다. 브라우저가 프래그먼트를 요청에 보내지 않으므로 서버 측 코드는 프래그먼트에 접근할 수 없습니다.

리다이렉트 체인 디버깅하기. curl -L -v https://example.re/start 를 실행하면 모든 리다이렉트를 따라가며 각 홉의 상태 코드와 헤더를 볼 수 있습니다. DevTools의 Network 탭에서도 전체 체인을 확인할 수 있습니다. 문서 유형으로 필터링하면 하위 리소스 요청과 리다이렉트 응답을 구분할 수 있습니다.