본문 바로가기
기억 할 것들

301 vs 302 redirect

by jay-choe 2022. 2. 19.

요청에대한 응답으로 redirect를 시켜야 할 경우 301 혹은 302 status code를 사용하게 된다.

기존에 둘의 차이가 단지 301은 영구적 이동, 302는 임시적 이동 이라는 개념으로만 알고 있었고 실제로 redirect를 응답으로 주어야 하는 경우에 어떤 것을 주어야 할지 감이오지 않아서 정리하게 되었다.

 

하지만 결과적으로 리다이렉트 되는 것은 동일한데 둘은 어떤 차이가 있을까 궁금했다.

 

10.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).
If the 301 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.

 

스택오버플로우에서 해당 내용에관한 RFC 문서에서 관련된 내용만 따온 부분을 가져왔다.

 

정리하자면

301 Redirect는 영원히 이동된 것이기 떄문에 이후에 동일 요청이 캐싱될 수 있음 처음 요청 이후 요청은(서버를 거치지 않고 바로 클라이언트에서 요청을 보냄)

 

This response is cacheable unless indicated otherwise.

 

0.3.3 302 Found
The requested resource resides temporarily under a different URI.
Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header
field.
The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).
If the 302 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.

 

302 redirect는 브라우저에서 캐싱이 가능하지만 Cache-control이나 Expire header를 명시해주어야 한다.

 

즉 301은 default로 브라우저 내에서 캐싱이 된다.

 

만약 특정 URL을 거쳐서 다른 사이트로 리다이랙트 시킬 때, 301을 쓴다면 처음 부분만 서버를 거치고 이후에 특정기간은 브라우저 캐싱이 되기 때문에 서버로직을 거치지 않는다.

 

즉, 만약 필요에 의해서 서버로직을 거치고 리다이랙트를 시켜야 하는 경우는 302 redirect 적절하다.

 

추가적으로 SEO 관련해서도 이야기가 있는데 궁금하면 찾아보면 좋을 것 같다.

 

 

 

참고:

- https://stackoverflow.com/questions/13203572/url-shortener-301-redirection-understanding

'기억 할 것들' 카테고리의 다른 글

Jpa 영속성전이(Cascade) 및 고아 객체  (0) 2021.09.26
X-Forwarded_FOR(XFF)  (0) 2021.09.13
쉘에서 유저 변경하기  (0) 2021.07.31