Retry-after HTTP 응답 헤더-영향을 미칩니 까?

Retry-after HTTP 응답 헤더-영향을 미칩니 까?

---

일시적인 과부하로 인해 웹 사이트에서 서비스를 정중하게 거부하고 싶다면 HTTP 응답 503 Service Unavailable 이 적절 해 보입니다. 사양 은 503과 함께 Retry-after 헤더를 보내는 것을 언급합니다 .

요점이 있습니까? Retry-after가 영향을 미칩니 까? 브라우저가 그것에주의를 기울입니까?

---

내가 아는 한, 어떤 브라우저도 Retry-after헤더에 주의를 기울이지 않습니다 . 프록시와 캐시는 가능하지만

분명히 일부 브라우저는 이제 일정 수준의 지원을 포함합니다 Retry-After(지원은 여전히 ​​기껏해야 지원이 충분하지 않음). 나는 브라우저에서 그렇게하는 것의 이점을 완전히 확신하지 못합니다. 일반적으로 오류를 캐시하는 것은 나쁜 생각으로 간주됩니다. 그러나 언제 다시 요청을 수락할지 안다면 클라이언트에게 해를 끼칠 수 없다고 말하십시오. (예상보다 빨리 돌아 오면 실제로 헤더를 따르는 프로그램은 사이트가 아직 다운되었다고 가정하고보고해야합니다.)

가장 분명한 이점은 Googlebot (및 기타 스파이더)이 헤더가있는 경우 헤더에주의를 기울여 잠시 동안 페이지 색인을 해제하지 못하게 할 수 있다는 것입니다.

추가하는 것이 사소한 일이고 서비스를 사용할 수있는시기를 합리적으로 정확하게 예측할 수 있다면 그렇게하십시오. 그러나 나는 그것을하기 위해 당신의 방식대로 나가는 것을 권하지 않을 것이다. 어쨌든 권고 일 뿐이며 잘못된 시간을 넣으면 헤더를 전혀 포함하지 않는 것보다 더 많은 문제가 발생할 수 있습니다.

---

Retry-After 헤더 의 현재 상태

클라이언트와 서버 의 Retry-After 헤더 구현은 이 질문이 처음 게시 된 이후 최근 몇 년 동안 약간 변경되었습니다. 그래서 나는 업데이트 된 답변을 제공 할 것이라고 생각했습니다.

먼저 RFC 2616, 섹션 14.37 Retry-After 상태 :

Retry-After 응답 헤더 필드는 503 (서비스를 사용할 수 없음) 응답과 함께 사용하여 요청하는 클라이언트가 서비스를 사용할 수 없을 것으로 예상되는 시간을 나타낼 수 있습니다.

...

사용의 두 가지 예는 다음과 같습니다.

  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
  Retry-After: 120

후자의 예에서 지연은 2 분입니다.

클라이언트 및 서버 소프트웨어 지원

다음은 다양한 소프트웨어 의 Retry-After 헤더 와 관련된 코드 저장소 커밋 메시지, 공지 사항 및 설명서 입니다.

크롬 / 크롬

로그 메시지와 함께 2012 년 11 월 22 일에 코드 커밋 : 검색 시간 초과 및 Retry-After HTTP 헤더 사용이 추가되었습니다 .

모질라 파이어 폭스

2012 년 3 월 27 일에 로그 메시지로 코드 커밋 : Implement Handling of 5xxs, X-Weave-Backoff, Retry-After . 또한 Mercurial 저장소 에 Retry-After 헤더 에 대한 세 가지 다른 언급이 있습니다.

2004 년 1 월 6 일 에 HTTP 503 응답과 함께 전송 된 Retry-After가 무시된다는 제목의 버그가 처음 제출되었습니다 .

Googlebot

사이트 다운 타임 처리에 대한 Google 웹 마스터 센터 블로그 기사에는 Retry-After 헤더를 사용하여 URL을 재 크롤링 할시기를 결정할 수 있다고 언급되어 있습니다 .

Bingbot / Msnbot

공식 Retry-After 지원 문서를 찾을 수 없습니다. 그러나 Microsoft의 봇을 제한하기 위해 503 응답에서이 헤더를 사용하는 것에 대해 무작위 포럼에서 몇 가지 언급이있었습니다.

Nginx

add_header 지시문 상태 :

응답 코드가 200, 201, 204, 206, 301, 302, 303, 304 또는 307 인 경우 지정된 필드를 응답 헤더에 추가합니다.

따라서 버전을 사용하여 503 응답에 대한 Retry-After 헤더를 추가하려면 다음을 수행하십시오.

• 1.7.4 이하 버전에서는 Headers More 와 같은 타사 모듈을 사용합니다 .

• 1.7.5 이상에서는 always매개 변수를 add_header지시문에 추가하십시오 .

Apache

Nginx와 달리 Apache 헤더 문서 에는 503 응답에 Retry-After 헤더를 보낼 수 없다는 표시가 없습니다. 그러나 비 -2xx 응답과 관련하여 문서는 다음과 같이 설명합니다.

리디렉션과 같이 로컬로 생성 된 비 성공 (비 -2xx) 응답에 헤더 추가.이 경우 항상에 해당하는 테이블 만 최종 응답에 사용됩니다.

다음은 문서에서 알 수 있듯이 503 응답에 대한 항상 조건 으로 Retry-After 헤더를 설정 하는 SO 답변 입니다 .

AskApache 기사는 Retry-After 헤더가있는 503 응답을 사용하여 검색 엔진이 다시 돌아 오도록 지시 하는 방법에 대한 다른 구성 예제를 제공합니다 .

클라이언트 테스트

Retry-After 헤더가 10 초로 설정된 503 응답과 임의의 숫자를 포함하는 본문을 반환하는 Ruby 서버를 작성했습니다.

require 'sinatra'

get '/' do
  headers 'Content-Type' => 'text/plain', 'Retry-After' => '10'
  status 503
  body rand(1000).to_s
end

나는 그것을 액세스했다 :

• Chromium 44, Firefox-ESR 38 및 Seamonkey 2.33을 사용하는 OpenBSD 5.8,
• Chrome 47 및 Safari 6.1을 사용하는 Mac OSX 10.7.5,
• Chrome 48, Firefox 41 및 Edge 25를 사용하는 Windows 10.

I was expecting these browsers to automatically refresh the URL after 10 seconds and display a new random number. However, all browsers did not retry, even after several minutes. I tried shorter and longer Retry-After periods as well with the same results. The server access log confirmed no retry was ever made from any of these browsers.

Also, a "soft" refresh before the Retry-After period refetched the URL immediately. So the Retry-After header cannot be used to throttle "refresh-happy" users. I mention this because I saw in some forum that this header could be used to throttle impatient users from hammering your site.

As a side note, it seems logical for a "soft" refresh to have no action before the timeout period, but a "hard" or cache-bypass refresh would ignore any timeout and immediately refetch the URL.

Conclusion

Support for the Retry-After header still seems a bit sketchy on both clients and servers. Nonetheless, it is a good idea to set a retry timeout for 503 responses if it is not difficult to configure.

Even if Googlebot is the only client supporting the header and actually retrying after the timeout period, it may keep your pages from being de-indexed -- as opposed to a 404, 500, 502, or 504 response.

---

I see this as a chicken-and-egg problem: No browsers currently implement Retry-after since no websites bother to. In my opinion, go ahead and send it as a service to the users. If their choice of web browser doesn't implement it, then that is their browser just not giving them useful information. You did!

When looking to implement standards which have multiple, competing implementations, I always try to adhere to the standards and not pay attention to the different implementations (unless I am specifically trying to emulate an implementation, such as cURLing but disguising my headers to look like a web browser). Otherwise, we end up with defacto standards, which if you remember the IE-dominence days you don't want!

---

If you want send an automatically refresh after X time you could send a

Refresh: 120; url=http://your_url.com

in PHP:

header("Refresh: "    .$retry_time."; url=". $url);

To refresh the current page you can use $_SERVER["REQUEST_URI"] for $url.

I tested this header successfull in different versions of Opera, Firefox and Internet Explorer.

This header even Works to refresh binary content like images (but only when the where loaded directly or in a frame - an IMG-Tag won`t reload).

ReferenceURL : https://stackoverflow.com/questions/3764075/retry-after-http-response-header-does-it-affect-anything