우리는 nginx 내부 301 및 302 처리를 사용할 때 nginx가 적절한 Location: ... 헤더가 있는 작은 문서 본문을 제공한다는 것을 확인했습니다.
(html로): 301 리디렉션 - nginx와 같은 내용입니다.
위 동작에 적절하게 콘텐츠 유형 text/html 및 콘텐츠 길이 헤더도 전송됩니다.
우리는 302 및 일부 301 리디렉션을 많이 수행합니다. 위의 동작은 우리 의견으로는 대역폭을 낭비하는 것입니다.
이 동작을 비활성화하는 방법이 있습니까?
우리 마음속에 떠오른 아이디어 중 하나는 error_page 301 302를 빈 텍스트 파일로 설정하는 것이었습니다. 아직 테스트하지는 않았지만 위의 경우에도 content-type 및 content-length (0) 헤더가 전송될 것이라고 가정합니다.
그렇다면 nginx를 사용하여 "본문이 없는" 301/302 리디렉션을 보내는 깔끔한 방법이 있습니까?
답변1
당신이 요구하는 것이 무엇인지 매우 신중하게 생각하고, 강력히 고려하십시오.안 하고 있어.
RFC 2616제거하려는 엔터티 본체가 있어야 함을 지정합니다.
10.3.2 301 영구적으로 이동됨
새로운 영구 URI는 응답의 위치 필드에 의해 제공되어야 합니다. 요청 방법이 HEAD가 아닌 한, 응답 엔터티에는 새 URI에 대한 하이퍼링크가 포함된 짧은 하이퍼텍스트 메모가 포함되어야 합니다.
그리고...
10.3.3 302 발견
임시 URI는 응답의 위치 필드로 제공되어야 합니다. 요청 방법이 HEAD가 아닌 한, 응답 엔터티에는 새 URI에 대한 하이퍼링크가 포함된 짧은 하이퍼텍스트 메모가 포함되어야 합니다.
SHOULD는 이 맥락에서 다음에 정의되어 있습니다.RFC 2119:
이 단어 또는 형용사 "권장"은 특정 상황에서 특정 항목을 무시할 타당한 이유가 있을 수 있지만 다른 과정을 선택하기 전에 전체 의미를 이해하고 신중하게 평가해야 함을 의미합니다.
이제 RFC를 위반하지 않고도 이 작업을 수행할 수 있지만 다음과 같은 전체 의미를 알고 있어야 합니다.
- 당신은 사실상 아무 유익도 없이 많은 일을 하고 있습니다. 제가 생각할 수 있는 엔터티 본문을 비활성화하는 유일한 논리적 이유는 대역폭 비용을 절약하기 위한 것입니다. 실제로 이것이 귀하가 언급한 이유이지만 차이가 너무 작아서 대역폭 그래프에서 차이를 볼 가능성조차 거의 없습니다.
- 웹 클라이언트의 아주 작은 부분은 자동으로 3xx 리디렉션을 따르지 않습니다. RFC가 작성되었을 때 이 부분은 훨씬 더 컸기 때문에 애초에 이것이 존재했지만, 여전히 어두운 침실과 데이터 센터 벽장의 그림자 속에 고대의 괴물들이 숨어 있고 때로는 놀러 나오기도 합니다. 가장 많이 볼 수 있는 것은
curl여전히 일반적으로 사용되는 입니다.
이 권장사항은 다음과 같이 다소 완화되었습니다.RFC 7231, 이는 단지 다음과 같습니다(301 및 302 모두에 대해).
서버의 응답 페이로드에는 일반적으로 새 URI에 대한 하이퍼링크가 포함된 짧은 하이퍼텍스트 메모가 포함되어 있습니다.
서버의 응답 페이로드에는 일반적으로 다른 URI에 대한 하이퍼링크가 포함된 짧은 하이퍼텍스트 메모가 포함되어 있습니다.
답변2
그래 넌 할수있어전적으로NGINX로 해보세요!
간단히 예외 처리기를 설치하면 됩니다.
error_page, 필수 응답을 사후 처리합니다. 오류 페이지가 HTTP 상태 코드를 수정하는 것을 방지하는 방식으로 설정하십시오. 예를 들어 매개변수를 사용하지 마십시오=(또는 원하는 코드를 하드코딩하는 데 매개변수를 사용하십시오).반드시
return[text]가 아닌 을 선택적으로 설정할 수 있는 반환 상태 코드가 포함된 응답입니다URL.지정하다
default_typeof , 헤더가""제거된 것으로 나타남Content-Type
전체 코드는 다음과 같습니다. 내 사이트에도 있습니다.GitHub~에StackOverflow.cnst.nginx.conf저장소:
# cat sf.421976.301-302-redirect-w-no-http-body-text.nginx.conf | sed 's#^#\t#g'
server {
listen 1976;
error_page 301 302 @30x; # keep original HTTP status code w/o `=`
location @30x {
default_type ""; # will remove Content-Type completely
# `300` is a filler: client will get the original HTTP status code
return 300;
}
return 301 http://example.su/test;
}
제대로 작동하는지 확인하는 방법은 다음과 같습니다.
% curl -i localhost:1976 | sed 's#^#\t#g'
HTTP/1.1 301 Moved Permanently
Server: nginx/1.2.1
Date: Mon, 28 Aug 2017 22:02:41 GMT
Content-Length: 0
Connection: keep-alive
Location: http://example.su/test
%
브라우저에서 시도해 보았는데 거기에서도 잘 작동했습니다.
PS 또 다른 옵션은 소스 코드를 수정하고ngx_http_error_301_page등의 변수가 있는데 왜 어려운 길을 가는가?! ^_^
답변3
조금 추악하지만 아마도 301/302 요청을 프록시하고 Proxy_method를 사용하여 GET을 HEAD 요청으로 변경할 수 있습니다. 테스트하지는 않았지만 헤드 요청은 응답이 없는 헤더나 (희망적으로) content-* 헤더만 보내야 합니다.