Cache-Control : private이란 무엇입니까?

Cache-Control : private이란 무엇입니까?

---

chesseng.herokuapp.com을 방문하면 다음과 같은 응답 헤더가 나타납니다.

Cache-Control:private
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/css
Date:Tue, 16 Oct 2012 06:37:53 GMT
Last-Modified:Tue, 16 Oct 2012 03:13:38 GMT
Status:200 OK
transfer-encoding:chunked
Vary:Accept-Encoding
X-Rack-Cache:miss

그런 다음 페이지를 새로 고치고

Cache-Control:private
Connection:keep-alive
Date:Tue, 16 Oct 2012 06:20:49 GMT
Status:304 Not Modified
X-Rack-Cache:miss

캐싱이 작동하는 것 같습니다. 이것이 캐싱에 효과적이라면 Expires 및 Cache-Control : max-age 의 요점은 무엇입니까 ? 혼란을 더하기 위해 https://developers.google.com/speed/pagespeed/insights/ 에서 페이지를 테스트하면 "브라우저 캐싱 활용"이라는 메시지가 표시됩니다.

---

웹 서버에 헤더가 포함되어 있지 않아도 캐싱이 작동하는 이유에 대한 질문에 답변하려면 다음을 수행하십시오.

• 만료 : [a date]
• 캐시 제어 : max-age =[seconds]

서버는 중간 프록시에게 내용을 캐시하지 않도록 친절하게 요청했습니다 (즉, 항목은 개인 캐시 에만 캐시해야합니다 (예 : 자신의 로컬 컴퓨터에만)).

• 캐시 제어 : 개인

그러나 서버는 모든 종류의 캐싱 힌트를 포함하는 것을 잊었습니다.

• 그들은 Expires 를 포함하는 것을 잊었 으므로 브라우저는 그 날짜까지 캐시 된 사본을 사용하는 것을 알고 있습니다.
• 그들은 Max-Age 를 포함하는 것을 잊었 으므로 브라우저는 캐시 된 항목이 얼마나 오래 지속되는지 알고 있습니다.
• 브라우저가 조건부 요청을 수행 할 수 있도록 E-Tag 를 포함하는 것을 잊었습니다.

그러나 응답에 Last-Modified 날짜 가 포함 되었습니다.

Last-Modified: Tue, 16 Oct 2012 03:13:38 GMT

브라우저는 파일이 수정 된 날짜를 알고 있기 때문에 조건부 요청을 수행 할 수 있습니다 . 서버에 파일을 요청하지만 2012/10/16 3:13:38 이후 파일이 수정 된 경우에만 파일을 보내도록 서버에 지시합니다.

GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT

서버는 요청을 받고 클라이언트가 최신 버전을 이미 가지고 있음을 인식합니다. 클라이언트를 보내고 200 OK페이지의 내용을 보내는 대신 캐시 된 버전이 양호 함을 알려줍니다.

304 Not Modified

브라우저가 서버에 요청을 보내는 데 시간이 걸리고 응답을 기다리는 데 어려움이 있었지만 정적 콘텐츠를 다시 다운로드해야하는 비용을 절약했습니다.

왜 최대 연령 ? 왜 만료 됩니까?

때문에 마지막으로 수정 안됐다.

서버의 모든 날짜와 관련된 날짜 가 있는 것은 아닙니다 . 나는 즉시 페이지를 짓고 있어요 경우, 그것과 관련된 일이 없다 - 그것의 지금 . 그러나 사용자가 15 초 동안 홈페이지를 캐시하도록 완벽하게 기꺼이합니다.

200 OK
Cache-Control: max-age=15

사용자가 망치면 F515 초 동안 캐시 된 버전을 계속 얻습니다. 회사 프록시 인 경우 동일한 15 초 동안 동일한 페이지를 방문하는 모든 67198 명의 사용자가 모두 동일한 내용을 얻습니다. 모두 캐시에서 제공됩니다. 모두를위한 성능 승리.

추가의 미덕은 Cache-Control: max-age브라우저가 조건부 요청 을 수행 할 필요가 없다는 것 입니다.

• 지정한 경우에만 Last-Modified브라우저가 요청을 수행 If-Modified-Since하고 304 Not Modified응답을 감시해야합니다.
• 을 지정 max-age하면 브라우저가 네트워크 왕복을 겪을 필요조차 없습니다. 내용은 캐시에서 바로 나옵니다.

"Cache-Control : max-age"와 "Expires"의 차이점

Expires현대 (c. 1998) Cache-Control: max-age헤더 와 동등한 유산입니다 .

• Expires: 당신은 날짜를 지정합니다 (요)
• max-age: 초를 지정합니다 (양호)

• 그리고 둘 다 지정되면 브라우저는 다음을 사용합니다 max-age.

  200 OK
  Cache-Control: max-age=60
  Expires: 20180403T192837 
  

1998 년 이후에 작성된 웹 사이트는 Expires더 이상 사용 하지 말고 대신 사용하십시오 max-age.

ETag 란 무엇입니까?

ETag 는 Last-Modified 와 비슷하지만 날짜 일 필요는 없습니다. 단지 무언가 일뿐 입니다.

If i'm pulling a list of products out of a database, the server can send the last rowversion as an ETag, rather than a date:

200 OK
ETag: "247986"

My ETag can be the SHA1 hash of a static resource (e.g. image, js, css, font), or of the cached rendered page (i.e. this is what the Mozilla MDN wiki does; they hash the final markup):

200 OK
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

And exactly like in the case of a conditional request based on Last-Modified:

GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT

304 Not Modified

I can perform a conditional request based on the ETag:

GET / HTTP/1.1
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

304 Not Modified

An ETag is superior to Last-Modified because it works for things besides files, or things that have a notion of date. It just is

---

Cache-Control: private

Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache, such as a proxy server.

From RFC2616 section 14.9.1

---

RFC 2616, section 14.9.1:

Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache...A private (non-shared) cache MAY cache the response.

---

Browsers could use this information. Of course, the current "user" may mean many things: OS user, a browser user (e.g. Chrome's profiles), etc. It's not specified.

For me, a more concrete example of Cache-Control: private is that proxy servers (which typically have many users) won't cache it. It is meant for the end user, and no one else.

---

FYI, the RFC makes clear that this does not provide security. It is about showing the correct content, not securing content.

This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message content.

---

The Expires entity-header field gives the date/time after which the response is considered stale.The Cache-control:maxage field gives the age value (in seconds) bigger than which response is consider stale.

Althought above header field give a mechanism to client to decide whether to send request to the server. In some condition, the client send a request to sever and the age value of response is bigger then the maxage value ,dose it means server needs to send the resource to client? Maybe the resource never changed.

In order to resolve this problem, HTTP1.1 gives last-modifided head. The server gives the last modified date of the response to client. When the client need this resource, it will send If-Modified-Since head field to server. If this date is before the modified date of the resouce, the server will sends the resource to client and gives 200 code.Otherwise,it will returns 304 code to client and this means client can use the resource it cached.

참고URL : https://stackoverflow.com/questions/12908766/what-is-cache-control-private