왜 OkHttp는 If-Modified-Since 헤더를 설정할 때 Last-Modified 헤더를 처리하는 것과 동일한 Date 헤더를 취급합니까?

Question

Github API와의 통합을 처리하기 위해 OkHttp 라이브러리를 사용하는 Jenkins 플러그인을 사용하고 있습니다.

OkHttp가 리소스에 액세스 할 수없는 토큰으로 리소스를 요청하려고하면 Github의/repos/: owner/: repo endpoint가 오류 404를 반환합니다. 토큰의 범위가 리소스에 액세스 할 수 있도록 확장되면 OkHttp는 If-Modified-Since 헤더로 요청을 수행합니다. 헤더의 값은 404 응답의 Date 헤더 값으로 설정됩니다. 이 두 번째 요청의 응답은 HTTP 304입니다. Github의 지원 팀에 따르면 첫 번째 요청이 있던 이후 자원 (/ repos/: 소유자/: repo 끝점 뒤에있는 데이터)이 수정되지 않았기 때문에이 동작이 적절한 동작입니다. 만든. 그러나 이는 OkHttp 클라이언트가 이제 캐시 된 404 응답을 사용함을 의미합니다.

Date 헤더는 리소스를 마지막으로 수정 한 시간을 확인하지 않고 신선도를 계산하기위한 것 같습니다. RFC 7232 section 3.3은 클라이언트가 Date 헤더의 값을 If-Modified-Since 값으로 사용할 수 있다고 말합니다. 그러나이 동작이 받아 들여지는 것을 제안하는 웹의 다른 문서를 찾지 못했습니다. Mozilla's documentation on the If-Modified-Since header에 Date 헤더에 대한 참조가 표시되지 않습니다.

Postel의 법률은 OkHttp가 If-Modified-Since 헤더의 다른 소스로 사용하여 Date 헤더를 오용하지 않도록해야한다고 제안하지 않았습니까?

Answer 1

RFC는 어떤 행동이 적절한 지 결정적입니다. RFC에 Date 헤더가 If-Modified-Since과 함께 사용될 수 있다고 나와 있으면 그럴 수 있습니다.

범위가 확장 될 때 GitHub에서 캐시를 무효화하도록 설득하는 것이 좋습니다. 2017-03-01에 응답이 제공되고 토큰의 범위가 2017-04-01에 확장 된 경우 자원은 2017-04-01에 효과적으로 수정되었습니다.

다른 옵션은 OkHttp의 캐시를 비활성화하는 것입니다. 모든 캐시와 마찬가지로, 캐시 캐시 구성의 지침을 준수함으로써 Postel 's Law를 위반합니다.