[HTTP 프로토콜 강좌]#18 HTTP 응답 헤더 III - Retry-After

응답헤더가 많이 남은줄 알았는데, 하다보니 Retry-After 하나 남아 있다.
응답헤더를 마무리 하고 일반 헤더를 이 포스팅에 정리를 해보려고 하니.. 글 제목이 좀 걸린다.

오늘은 응답헤더를 마무리하는데 의미를 두고, 남아 있는 Retry-After 하나만 정리하기로 한다.

1. Retry-After

Retry-After 응답헤더는 뭐, 단어의미에서 바로 이해할 수 있을것이라 본다.
"다시 접속을 시도해 주세요" 라는 메시지를 웹서버가 클라이언트에게 주고 싶을 때 Retry-After 헤더를 사용할 수 있다.

웹서버가 서비스 불능 상태에 빠진 경우, 이 때 아무것도 모르는 클라이언트가 접속을 시도했다고 생각해 보자. 당연히 웹서버는 클라이언트가 요청한 컨텐츠를 제공해 줄 수 없으니 에러 메시지를 전달하게 될 것이다. 바로 이때, 서비스가 복구될 시점을 알려준다면 얼마나 좋겠는가?

웹서버의 주소가 이전된 경우를 생각해 보자.
회사 이름이 변경되어 잘 운영하고 있던 도메인 "www.compay.com" 이라는 주소가 다른 이름으로 변경되었다면, 우리는 전에 배웠던 location 헤더를 이용해서 주소를 리다이렉트 할 수 있다. 그런데 클라이언트에게 적당한 메시지를 전달하지 않고 바로 redirect 하게 되면 이게 왜 리다이렉트 되는지 의심을 하게 된다.
이상황이 정상인가? 아니면 악의적은 어떤 목적이 있는건가? 라는 등등....

그렇다면 리다이렉트 되기 전에 잠깐이라도 "회사이름 변경으로 인해 페이지를 이동합니다." 라는 메시지를 준다면, 이런 오해나 의심을 해소할 수 있지 않겠는가?
바로 이 경우 Retry-After 를 이용할 수 있다.

Retry-After 헤더는 그 값으로 다음 두가지 형태를 갖는다.

• 특정 날짜 시점 : 주로 "503 Service Unavailable" 과 같이 사용됨
• Retry-After: Mon, 1 Jan 2017 09:30:10 GMT
• 시간 (초) : 주로 3XX 리다이렉트 메시지와 같이 사용됨
• Retry-After: 120

Retry-After 의 목적은 어느정도 이해했으리라 본다. 

하지만, 테스트를 해 봤는데 안타깝게도 현재 클라이언트가 사용하는 웹브라우저 (크롬,IE,MS Edge, Firefox등)는 Retry-After 를 무시해 버린다. 

자료를 좀 조사해 보니, 검색봇(Googlebot등)은 Retry-After 헤더를 잘 지키고 있다고 한다. 

때문에 검색봇이 웹사이트에 들어왔는데, "503 Service Unavailable" 인 경우 Retry-After 헤더를 참고해서 그 때까지는 검색봇이 결과를 찾기 위해 웹사이트에 방문하는 시도를 하지 않는다고 하니, 참고토록 하자..

여기까지 해서 응답헤더를 마친다. 

다음에는 헤더의 마지막인 일반 헤더 (General Header) 를 다루도록 한다.