Indy 的 HandleRedirect 是做什么的？
我在使用 Indy 从安装了 WordPress 的网站读取文件时遇到一些问题。
该站点似乎已配置为将所有点击重定向到 sitename/com/wordpress。
我可以使用 HandleRedirect 将其关闭，以便我可以从根文件夹读取文件吗？
该属性的正常设置是什么？将其用于此目的有什么缺点吗？
（编辑：看来我的问题可能是由 Windows 缓存我之前通过 Indy 访问过的文件引起的。我正在使用 fIDHTTP.Request.CacheControl := 'no-cache'；这样就足够了吗？
I'm having some trouble reading files with Indy from a site that has WordPress installed.
It appears that the site is configured to redirect all hits to sitename/com/wordpress.
Can I use HandleRedirect to turn that off so I can read files from the root folder?
What is the normal setting for this property? Any downsides to using it for this purpose?
(Edit: it appears that my problem may be caused by Windows cacheing of a file I've accessed before through Indy. I'm using fIDHTTP.Request.CacheControl := 'no-cache'; is that adequate?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当服务器发送请求的 3xx 结果时，
HandleRedirects属性控制 Indy 是否立即转身并使用新位置发出新请求。另一种方法是 Indy 会将响应代码返回给您的程序。欢迎您自己使用OnRedirect事件来处理它，但是如果服务器除了响应代码之外还费心发送任何内容，那么它不太可能对您的程序有多大用处。这并不是说存在重定向阻止您下载的隐藏文件。将属性设置为 true 并让 Indy 为您处理重定向。Windows 可能没有为您的程序缓存任何内容。 Indy 不使用操作系统缓存。 Cache-Control 标头是向代理或所谓的源服务器发出的指令，表示在未与源服务器进行验证的情况下，不应使用缓存的响应来满足您的请求。也许 WordPress 有自己的缓存，您正在绕过它。
When the server sends a 3xx result for a request, the
HandleRedirectsproperty controls whether Indy will immediately turn around and issue a new request using the new location. The alternative is that Indy will return the response code to your program. You're welcome to handle it yourself with theOnRedirectevent, but if the server bothers to send anything in addition to the response code, it's unlikely to be of much use to your program. It's not as though there are hidden files that the redirection is preventing you from downloading. Set the property to true and let Indy take care of the redirection for you.It's probably not the case that Windows is caching anything for your program. Indy doesn't use the OS cache. The Cache-Control header is an instruction to a proxy or the so-called origin server that it should not satisfy your request using a cached response without validating it with the origin server. Maybe WordPress has a cache of its own that you're by-passing.