How do clients using my web service bypass the transparent cache of the ISP proxy server to allow them access to my server?

I wrote a RESTful web service that is consumed only by devices, not browsers. Devices access the Internet through the owner of the home home router and communicate with the web service by sending HTTP requests through the router as often as every 30 seconds. These queries are basically β€œpolling” queries to find out if the web service has any new information for the device.

I want any transparent ISP proxies to intercept the request and return a cached response. I read that one way to do this is to add a random request line to the end of the request URL in order to trick the proxy into considering it to be a unique request. For example:

http://webservicedomain.com/poll/?randomNumber=384389 

I have the ability to do this, but is this the best way? Kinda seems to be a hack.

+7
source share
3 answers

To achieve this, you must use HTTP cache control .

In response you should send:

 Cache-Control: private, must-revalidate, max-age=0 
  • private Indicates that all or part of the response message is for one user and SHOULD NOT be cached by the shared cache.
  • max-age = 0 - indicates that the client is ready to accept a response whose age does not exceed 0 seconds. That is, the answers immediately freeze.
  • must-revalidate . If this cache is present in the response received by the cache, this cache MUST NOT use this entry after it becomes obsolete in order to respond to a subsequent request without first checking it with the source server.

You can also send a Pragma header for legacy HTTP / 1.0 staging server servers:

 Pragma: no-cache 

Related reading:

+14
source

You can try using an encrypted connection. I think cache proxies should not store responses from encrypted communications.

One solution might be to configure HTTPS on your server, and another to configure the client to use one of the SSL proxies to send requests to your HTTP server.

+1
source

With appropriate Cache controls and other headers, of course, use POST and voila! This may solve the problem you have reported.

You might want to see this - a discussion of caching

Then, an extra pass of the parameter could be avoided.

+1
source

All Articles