HTTP로 POST 메소드를 캐시 할 수 있습니까?
매우 간단한 캐싱 의미론을 사용하면 매개 변수가 동일하고 URL이 동일하면 적중합니다. 가능합니까? 추천?
섹션 9.5 (POST) 의 해당 RFC 2616 을 사용하면 적절한 헤더를 사용하는 경우 POST 메시지 에 대한 응답 을 캐싱 할 수 있습니다.
응답에 적절한 Cache-Control 또는 Expires 헤더 필드가 포함되어 있지 않으면이 방법에 대한 응답을 캐시 할 수 없습니다. 그러나 303 (기타 참조) 응답을 사용하여 사용자 에이전트가 캐시 가능한 자원을 검색하도록 지시 할 수 있습니다.
동일한 RFC는 섹션 13 (HTTP에서 캐시)에서 명시 적으로 POST 요청 후 캐시가 해당 엔티티를 무효화해야 함을 명시합니다 .
일부 HTTP 메소드는 캐시가 엔티티를 무효화하도록해야합니다. 이는 Request-URI 또는 Location 또는 Content-Location 헤더 (있는 경우)에 의해 참조되는 엔티티입니다. 이러한 방법은 다음과 같습니다.
- PUT - DELETE - POST
이러한 사양이 어떻게 의미있는 캐싱을 허용 할 수 있는지는 확실하지 않습니다.
RFC 2616 섹션 9.5에 따르면 :
"응답에 적절한 Cache-Control 또는 Expires 헤더 필드가 포함되어 있지 않는 한 POST 방법에 대한 응답은 캐시 할 수 없습니다."
예, POST 요청 응답을 적절한 헤더와 함께 도착한 경우에만 캐시 할 수 있습니다. 대부분의 경우 응답을 캐시하고 싶지 않습니다. 그러나 서버에 데이터를 저장하지 않는 경우와 같은 일부 경우에는 전적으로 적합합니다.
그러나 현재 Firefox 3.0.10을 포함한 많은 브라우저는 헤더에 관계없이 POST 응답을 캐시하지 않습니다. IE는 이런 점에서보다 현명하게 행동합니다.
이제 RFC 2616 S에 대한 혼란을 해결하고 싶습니다. 13.10. URI의 POST 메소드는 여기에 언급 된대로 "캐싱 할 자원을 무효화"하지 않습니다. 캐시 제어 헤더가 더 오래 지속되는 신선도를 표시하더라도 이전에 캐시 된 해당 버전의 URI를 무효로 만듭니다.
사무용 겉옷:
기본적으로 POST는 dem 등원 작업이 아닙니다 . 따라서 캐싱에 사용할 수 없습니다. GET은 dem 등원 작업이어야하므로 캐싱에 일반적으로 사용됩니다.
HTTP 1.1 RFC 2616 S. 9.1 섹션 9.1을 참조하십시오 .
GET 메소드의 의미 이외의 것 :
POST 메소드 자체는 의미 적으로 자원에 무언가를 게시하기위한 것입니다. POST를 캐시 할 수 없습니다. 한 번 대 두 번 대 세 번 작업을 수행하면 매번 서버 리소스가 변경되기 때문입니다. 각 요청은 중요하며 서버로 전달되어야합니다.
PUT 메소드 자체는 의미 상 자원을 넣거나 작성하기위한 것입니다. dem 등원 작업이지만 그 동안 DELETE가 발생할 수 있으므로 캐싱에 사용되지 않습니다.
DELETE 메서드 자체는 의미 상 리소스를 삭제하기위한 것입니다. dem 등원 작업이지만 그 동안 PUT이 발생할 수 있기 때문에 캐싱에 사용되지 않습니다.
클라이언트 측 캐싱과 관련하여 :
웹 브라우저는 이전 POST 작업의 응답이 있더라도 항상 요청을 전달합니다. 예를 들어 며칠 간격으로 gmail로 이메일을 보낼 수 있습니다. 제목과 본문은 같을 수 있지만 두 이메일을 모두 보내야합니다.
프록시 캐싱과 관련하여 :
메시지를 서버로 전달하는 프록시 HTTP 서버는 GET 또는 HEAD 요청 외에는 아무것도 캐시하지 않습니다.
서버 캐싱과 관련하여 :
기본적으로 서버는 캐시 확인을 통해 POST 요청을 자동으로 처리하지 않습니다. 물론 POST 요청을 응용 프로그램이나 추가 기능으로 보낼 수 있으며 매개 변수가 같을 때 읽은 자체 캐시를 가질 수 있습니다.
자원 무효화 :
당좌 2616 S. 13.10 HTTP 1.1 RFC를 POST 메서드 캐싱을위한 리소스를 무효화해야한다고 쇼.
POST 응답을 캐시하는 경우 웹 애플리케이션의 지시에 따라야합니다. 이는 "응답에 적절한 Cache-Control 또는 Expires 헤더 필드가 포함되어 있지 않으면이 방법에 대한 응답을 캐싱 할 수 없습니다"라는 의미입니다.
POST 결과가 dem 등원인지 아닌지를 아는 응용 프로그램이 필요하고 적절한 캐시 제어 헤더를 첨부할지 여부를 결정한다고 안전하게 가정 할 수 있습니다. 캐싱이 허용되는 헤더가있는 경우 애플리케이션은 실제로 POST가 슈퍼 GET임을 알려줍니다. POST 사용은 dem 등원 작업을 수행하는 데 필요한 불필요하고 관련이없는 (URI를 캐시 키로 사용하는) 데이터로 인해 필요했습니다.
이 가정에 따라 다음 GET을 캐시에서 제공 할 수 있습니다.
캐싱 가능 및 캐싱 불가능 POST 응답을 구별하기 위해 필요하고 올바른 헤더를 첨부하지 못한 응용 프로그램은 유효하지 않은 캐싱 결과에 결함이 있습니다.
즉, 캐시에 도달하는 각 POST는 조건부 헤더를 사용하는 유효성 검사가 필요합니다. 이는 오브젝트의 수명이 만료 될 때까지 POST 결과가 요청에 대한 응답에 반영되지 않도록 캐시 컨텐츠를 새로 고치기 위해 필요합니다.
실제로 사이트의 데이터를 변경하지 않는 것이면 GET 요청이어야합니다. 양식 인 경우에도 가져 오기 요청으로 설정할 수 있습니다. 다른 사람들이 지적했듯이 POST의 결과를 캐시 할 수는 있지만 정의에 의한 POST가 데이터를 변경하기 때문에 의미 론적으로 의미가 없습니다.
Mark Nottingham은 POST 응답을 캐시 할 수있을 때 분석했습니다. 캐싱을 활용하려는 후속 요청은 GET 또는 HEAD 요청이어야합니다. httpbis 도 참조하십시오
POST는 100에서 99 번의 식별 된 상태를 다루지 않습니다. 그러나 한 가지 경우가 있습니다. 서버가 요청 URI와 동일한 Content-Location 헤더를 설정하여이 POST 응답이 URI의 표현이라고 말하는 데 방해가되는 경우. 이런 경우 POST 응답은 동일한 URI에 대한 GET 응답과 같습니다. 캐시하고 재사용 할 수 있지만 향후 GET 요청에만 사용할 수 있습니다.
https://www.mnot.net/blog/2012/09/24/caching_POST .
Of course it's possible. If you want to catch POST requests sent to your server, and cache the data sent back to be re-sent later - no sweat.
The tricky part comes in regarding "state". How do you decide the data you want to send back to the user really should be the same? What if his cookies have changed - does that change the data you want to send back?
How about if the user made a POST request to your homepage, and since the last time he did that, another user sent him a message (using some system inside your site.) You would have to identify that as a change-of-state, and send the new version of your homepage, with a notification about the message to the user the next time he loads the homepage. Even if the POST parameters are the same.
With firefox 27.0 & with httpfox, on May 19, 2014, I saw one line of this: 00:03:58.777 0.488 657 (393) POST (Cache) text/html https://users.jackiszhp.info/S4UP
Clearly, the response of a post method is cached, and it is also in https. Unbelievable!
POST is used in stateful Ajax. Returning a cached response for a POST defeats the communication channel and the side effects of receiving a message. This is Very Very Bad. It's also a real pain to track down. Highly recommended against.
A trivial example would be a message that, as a side effect, pays your salary $10,000 the current week. You DON'T want to get the "OK, it went through!" page back that was cached last week. Other, more complex real-world cases result in similar hilarity.
참고URL : https://stackoverflow.com/questions/626057/is-it-possible-to-cache-post-methods-in-http
'IT' 카테고리의 다른 글
| Where 및 Select가 Select보다 우수한 이유는 무엇입니까? (0) | 2020.06.16 |
|---|---|
| Git이“블록 체인”으로 간주되지 않는 이유는 무엇입니까? (0) | 2020.06.16 |
| 자바 스크립트 이벤트를 마우스 오른쪽 버튼으로 클릭합니까? (0) | 2020.06.16 |
| Java JDK 소스 코드는 어디에서 찾을 수 있습니까? (0) | 2020.06.16 |
| Git을위한 좋은 무료 시각적 병합 도구는 무엇입니까? (0) | 2020.06.16 |