On 7/09/2012 9:39 a.m., Farkas H wrote:
Hi Amos,
thanks for your response.
I modified the web application. Now we have the following infrastructure.
client --> http-Post [embedded http-Get] --> Server / web application
--> http-Get --> Squid -> Servers (-> Squid -> Server / web
application -> client)
Advantage: The Server / web application doesn't have to request data
from the remote servers if it's in the Squid cache.
Additionally I want to cache the http-Post requests.
client --> http-Post --> Squid --> Server / web apllication /
processing the response (-> Squid -> client)
Requests body is not cacheable in HTTP.
The body content is the state to be changed at end-server resource in
the URL. Caching it is meaningless, since next time the state needs to
be changed you CANNOT simply reply from a middleware cache saying
"server state now changed" without passing any of those details to the
server.
Additionally, your translation service is re-writing the POST into GET
requests so the POST ceases to exist at your gateway service. There is
nothing to cache.
The idea: We modify the header of the http-post request to make it unique.
The information whether Squid has a stored response to the modified
request (true or false) should be added to the request / should be
forwarded to the destination server. There are two possibilities.
(1) The modified request is not stored in Squid (new request).
(2) The modified request is stored in Squid. We don't know yet if the
data is still fresh.
The request should be forwarded in both(!) possibilities, (1) and (2),
to the destination server.
Is that possible with Squid?
Of course. That is dependent on the Cache-Control: headers the server
supplies to Squid with its responses and applies to each response
independent of anythign else.
Send "Cache-Control: must-revalidate" and Squid will query the server
for each request asking if there are updates.
Amos
