HEAD 请求与 GET 请求
我一直认为，执行 HEAD 请求而不是 GET 请求速度更快（无论资源大小），因此在某些解决方案中具有优势。
然而，当在 Python 中发出 HEAD 请求（对 5+ MB 动态生成的资源）时，我意识到它花费了与发出 GET 请求相同的时间（几乎 27 秒）而不是我所希望的“不到 2 秒”）。
使用一些 urllib2 解决方案来发出此处找到的 HEAD 请求，甚至使用 pycurl （将 headers 和 nobody 设置为 <代码>真）。两人用的时间是一样的。
我在概念上错过了什么吗？是否可以使用 Python 执行“快速”HEAD 请求？
I always had the idea that doing a HEAD request instead of a GET request was faster (no matter the size of the resource) and therefore had it advantages in certain solutions.
However, while making a HEAD request in Python (to a 5+ MB dynamic generated resource) I realized that it took the same time as making a GET request (almost 27 seconds instead of the 'less than 2 seconds' I was hoping for).
Used some urllib2 solutions to make a HEAD request found here and even used pycurl (setting headers and nobody to True). Both of them took the same time.
Am I missing something conceptually? is it possible, using Python, to do a 'quick' HEAD request?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
服务器占用了大部分时间，而不是您的请求者或网络。如果它是动态资源，则服务器可能不知道所有标头信息 - 特别是内容长度 - 直到它构建为止。因此，无论您是执行 HEAD 还是 GET，它都必须构建整个事物。
The server is taking the bulk of the time, not your requester or the network. If it's a dynamic resource, it's likely that the server doesn't know all the header information - in particular, Content-Length - until it's built it. So it has to build the whole thing whether you're doing HEAD or GET.
响应时间由服务器决定，而不是由您的请求决定。 HEAD 请求返回的数据较少（仅是标头），因此从概念上讲它应该更快，但实际上，许多静态资源都被缓存，因此几乎没有可测量的差异（只是附加数据包通过网络传输的时间）。
The response time is dominated by the server, not by your request. The HEAD request returns less data (just the headers) so conceptually it should be faster, but in practice, many static resources are cached so there is almost no measureable difference (just the time for the additional packets to come down the wire).
有可能的是，该请求时间的大部分实际上是在服务器上生成 5+MB 响应的任何进程，而不是将其传输给您的时间。
在许多情况下，Web 应用程序在响应 HEAD 请求时仍然会执行完整的脚本 - 它只是不会将完整的正文发送回请求者。
如果您有权访问正在处理该请求的代码，则可以在其中添加一个条件，使其根据方法以不同的方式处理请求，这可以显着加快速度。
Chances are, the bulk of that request time is actually whatever process generates the 5+MB response on the server rather than the time to transfer it to you.
In many cases, a web application will still execute the full script when responding to a HEAD request--it just won't send the full body back to the requester.
If you have access to the code that is processing that request, you may be able to add a condition in there to make it handle the request differently depending on the the method, which could speed it up dramatically.