没有内置缓存TIdHTTP.GET
。
如果TIdHTTP
是缓存,它会发送一个条件获取(使用一个If-Modified-Since
标头),如果服务器正在合作,它会304
从服务器发回一个 HTTP 响应。如果是这种情况,通常情况下,您的 Web 服务器将能够检测到文件已更改并且不会返回 a 304
,而是提供文件的最新版本。如果这是问题所在,而且很可能不是,这将指向您将在服务器上解决的问题。
如果您在使用 的客户端和服务器之间遇到缓存问题,则客户端TIdHTTP.GET
可能会在到达 Web 服务器之前通过缓存 Web 代理(您甚至可能没有意识到)。通常,ISP 实施缓存 Web 代理以降低其带宽成本。
To signal caching mechanisms not to respond with a cached response, you can try including the Cache-Control: no-cache
header, or for backwards compatibility with HTTP/1.0, you could specify the Pragma: no-cache
header. If neither of those work for you, you may have to get more sophisticated.
As whsrdaddy suggested, one way to defeat an overzealous web caching proxy is to send an extra parameter that changes on each request, such as the date and time (down to the millisecond), or a randomly generated value. This way, the caching web proxy will forward the request to the web server rather than serving up a cached result simply because the URL changed.
POST
requests don't have the same problem, so be sure to use POST
whenever sending data to the server (modifications), and only use GET
when requesting resources (read only).