304 Not Modified 응답을 언제 보낼지 아는 방법

StackOverflow https://stackoverflow.com/questions/4506

  •  08-06-2019
  •  | 
  •  

문제

저는 다양한 파일에 대한 액세스를 제어하는 ​​리소스 처리 방법을 작성 중이며 브라우저의 캐시를 활용할 수 있도록 하고 싶습니다.내 질문은 두 가지입니다.

  1. 304 응답을 보내야 하는지 확실히 알기 위해 확인해야 하는 최종 HTTP 헤더는 무엇이며, 이를 확인할 때 무엇을 찾고 있습니까?

  2. 또한 처음에 파일(예: 'Last-Modified')을 200 응답으로 보낼 때 보내야 하는 헤더가 있습니까?

일부 의사 코드가 아마도 가장 유용한 답변이 될 것입니다.

캐시 제어 헤더는 어떻습니까?가능한 다양한 값이 클라이언트에 보내는 내용(즉, max-age)에 영향을 미칠 수 있습니까? 아니면 수정된 이후에만 준수해야 합니까?

도움이 되었습니까?

해결책

제가 구현한 방법은 다음과 같습니다.이 코드는 1년 넘게 여러 브라우저에서 작동해왔기 때문에 꽤 안정적이라고 생각합니다.이는 다음을 기반으로 합니다. RFC 2616 그리고 다양한 브라우저가 언제 무엇을 보내고 있는지 관찰함으로써 말이죠.

의사코드는 다음과 같습니다.

server_etag = gen_etag_for_this_file(myfile)
etag_from_browser = get_header("Etag")

if etag_from_browser does not exist:
    etag_from_browser = get_header("If-None-Match")
if the browser has quoted the etag:
    strip the quotes (e.g. "foo" --> foo)

set server_etag into http header

if etag_from_browser matches server_etag
    send 304 return code to browser

다음은 이를 처리하는 서버 로직의 일부입니다.

/* the client should set either Etag or If-None-Match */
/* some clients quote the parm, strip quotes if so    */
mketag(etag, &sb);

etagin = apr_table_get(r->headers_in, "Etag");
if (etagin == NULL)
    etagin = apr_table_get(r->headers_in, "If-None-Match");
if (etag != NULL && etag[0] == '"') {
    int sl; 
    sl = strlen(etag);
    memmove(etag, etag+1, sl+1);
    etag[sl-2] = 0;
    logit(2,"etag=:%s:",etag);
}   
... 
apr_table_add(r->headers_out, "ETag", etag);
... 
if (etagin != NULL && strcmp(etagin, etag) == 0) {
    /* if the etag matches, we return a 304 */
    rc = HTTP_NOT_MODIFIED;
}

etag 생성에 대한 도움이 필요하시면 다른 질문을 게시해 주세요. 해당 작업을 수행하는 코드도 찾아보겠습니다.HTH!

다른 팁

304 Not Modified 응답은 If-Modified-Since("IMS") 또는 If-Not-Match("INM") 헤더가 있는 GET 또는 HEAD 요청으로 인해 발생할 수 있습니다.

이러한 헤더를 수신할 때 수행할 작업을 결정하려면 이러한 조건부 헤더 없이 GET 요청을 처리한다고 가정해 보세요.해당 응답에 ETag 및 Last-Modified 헤더의 값이 무엇인지 결정하고 이를 사용하여 결정을 내립니다.이를 결정하는 것이 완전한 응답을 구성하는 것보다 비용이 적게 들도록 시스템을 구축하셨기를 바랍니다.

INM이 있고 해당 헤더의 값이 ETag에 배치한 값과 동일한 경우 304로 응답합니다.

IMS가 있고 해당 헤더의 날짜 값이 Last-Modified에 배치한 날짜 값보다 이후인 경우 304로 응답합니다.

그렇지 않으면 요청에 해당 헤더가 포함되지 않은 것처럼 진행합니다.

질문의 파트 2에 대한 최소한의 노력 접근 방식을 위해 웹 애플리케이션에서 쉽고 정확하게 생성할 수 있는 헤더(Expires, ETag 및 Last-Modified)를 파악하십시오.

추천 독서 자료:

http://www.w3.org/Protocols/rfc2616/rfc2616.html

http://www.mnot.net/cache_docs/

클라이언트가 캐시에 이미 페이지가 있을 수 있다고 명시적으로 명시한 경우 304를 보내야 합니다.이를 조건부 GET이라고 하며 다음을 포함해야 합니다. 수정된 이후 요청의 헤더.

기본적으로 이 요청 헤더에는 클라이언트가 캐시된 복사본이 있다고 주장하는 날짜가 포함되어 있습니다.이 날짜 이후에 콘텐츠가 변경되었는지 확인하고 변경되지 않은 경우 304를 보내야 합니다.

보다 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25 RFC의 관련 섹션에 대해 설명합니다.

또한 캐시되었지만 보안이 유지되는 리소스도 처리하고 있습니다.ETAg 헤더(RFC 2616 섹션 13.3에서 권장하는 사항)를 보내거나 생성하는 경우 클라이언트는 조건부 요청(일반적으로 If-None-Match - HTTP_IF_NONE_MATCH - 헤더)에서 이를 사용해야 합니다.Last-Modified 헤더를 보내는 경우(다시 한번 해야 함) If-Modified-Since - HTTP_IF_MODIFIED_SINCE - 헤더를 확인해야 합니다.둘 다 보내는 경우 클라이언트는 둘 다 보내야 하지만 ETag를 보내야 합니다.또한 유효성 검사는 조건부 헤더가 전송하려는 헤더와 완전히 동일한지 확인하는 것으로 정의됩니다.또한 범위 지정 요청(리소스의 일부만 요청되는 경우)에는 강력한 유효성 검사기(예: ETag)만 사용됩니다.

실제로 우리가 보호하는 리소스는 상당히 정적이고 1초의 지연 시간이 허용되므로 다음을 수행합니다.

  1. 사용자가 요청한 리소스에 액세스할 수 있는 권한이 있는지 확인하세요.

    그렇지 않은 경우 리디렉션하거나 적절하게 4xx 응답을 보냅니다.해킹 시도나 노골적인 보안 종료 실행 시도로 보이는 요청에 대해 404 응답을 생성합니다.

  2. If-Modified-Since 헤더를 엄격한 동일성을 위해 보낼 Last-Modified 헤더(아래 참조)와 비교하세요.

    일치하면 304 Not Modified 응답을 보내고 페이지 처리를 종료합니다.

  3. 요청한 리소스의 수정 시간을 사용하여 Last-Modified 헤더를 생성합니다.

    RFC 2616에서 HTTP 날짜 형식을 찾아보세요.

  4. 적절한 Content-Type과 함께 헤더 및 리소스 콘텐츠를 보냅니다.

우리는 ETag 헤더가 우리의 목적에 비해 너무 과하기 때문에 사용하지 않기로 결정했습니다.날짜 타임 스탬프를 ETag로 사용할 수도 있을 것 같습니다.진정한 ETag 시스템으로 전환한다면 아마도 리소스에 대해 계산된 해시를 저장하고 이를 ETag로 사용할 것입니다.

리소스가 데이터베이스 콘텐츠 등에서 동적으로 생성되는 경우 ETag는 적절하다고 판단되는 대로 채워지는 텍스트일 뿐이므로 요구 사항에 더 적합할 수 있습니다.

캐시 제어에 관하여:

캐시 제어를 합리적인 값으로 설정하는 것 외에는 서빙 시 캐시 제어에 대해 걱정할 필요가 없습니다.이는 기본적으로 캐시 시간이 초과되기 전에 경과해야 하는 최대 시간을 브라우저 및 기타 다운스트림 엔터티(예: 프록시)에 알려주는 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top