在Web服务器中实现HTTP ETag [英] Implementing HTTP ETags in a web server

查看:314
本文介绍了在Web服务器中实现HTTP ETag的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在研究在Web服务器中实现ETag的可能性,以仅支持条件GET. Web服务器是用C ++编写的,并且只能在Windows操作系统上运行.经过研究后,我有几个问题...实现此功能的服务器通常是否为特定文件缓存ETag GUID?我对Apache代码库不太熟悉,但是我能够找到ap_condition_if_none_match函数,但是对我来说,尚不清楚他们如何检查if-none-match标头的GUID值.如果他们确实缓存了东西,并且文件在服务器之外进行了任何更改(即用户更新了文件),那么服务器如何知道缓存中的文件不再有效?他们是否正在使用某些API监视"目录更改?

I'm currently looking into the possibility of implementing ETags in a Web Server, to support only the conditional GET. The Web Server is written in C++ and runs only on a Windows OS. After doing some research I have a few questions...Do servers that implement this feature generally cache the ETag GUID for a particular file? I'm not too familiar with the Apache code base, but I was able to locate the ap_condition_if_none_match function but, it isn't entirely clear to me how they check the GUID value for the if-none-match header. If they do cache things and the file were to change outside of the server doing anything (ie, user updated it), how would the server know the file in it's cache is no longer valid? Are they maybe using some API to "watch" for directory changes?

我正在查看在这里找到的一些信息: https://httpd.apache .org/docs/2.4/caching.html

I am reviewing some info I found here: https://httpd.apache.org/docs/2.4/caching.html

推荐答案

在Apache中,ETag由文件的索引节点,大小和最后修改时间组成:

In Apache, the ETag is made from the file's inode, size, and last-modified time: http://httpd.apache.org/docs/2.2/mod/core.html#FileETag

有不同的选项,您可以使它们可配置.我将为您提供可能的选项列表,从最小到最可靠:

There are different options, you can make them configurable. I will give you a list of possible options, from least to most reliable:

  1. [最快选项]检查上次文件修改时间,其频率高于1秒.例如,在Windows中,文件时间以100纳秒间隔测量.还要像Apache一样检查文件大小和inode.在Windows下,您可以通过GetFileInformationByHandle查询打开句柄的文件ID,而不是inode.参见nFileIndexHigh,nFileIndexLow;这是文件ID的高位和低位,分别为64位.如果文件时间,大小和索引节点已更改,请重新计算哈希值.
  2. [安全选项]除了文件时间,大小和索引节点外,还使用英特尔(SSE4.2)实现的非常快速的CRC32函数检查文件的内容–它比SSE4.2之前存在的任何CRC32实现都要快得多.如果文件时间或CRC32已更改,请重新计算哈希值.
  3. [快速和安全的选项但有用户处理]仅在服务器运行时计算哈希.服务器首次启动时,不应计算任何哈希值.如果首先请求文件,请计算哈希并存储它,直到服务器退出.在服务器运行期间,使用操作系统的文件更改通知监视(具有哈希值的文件的)文件更改.例如,在Widnows中,存在FindFirstChangeNotification.

对于ETag本身的哈希值,我会推荐一种加密哈希函数,即使是对于数字签名来说不再强大的哈希函数.我不建议使用没有明确设计为具有较强密码强度的哈希函数,因为它们不会产生像加密散列这样小的摘要,从而具有可比的抗碰撞能力.冲突是指两个不同的文件产生相同的哈希值. MD5的速度快且摘要大小小,因此它仍然非常适合文件内容更改监视.它是可用的最快的哈希函数.您还可以在汇编中找到快速的MD5实现,例如从OpenSSL或 https://www.nayuki.io/page/fast-md5-hash-implementation-in-x86-assembly

For the hash value of the ETag itself, I would have recommended a cryptographic hash function, even one that is no longer strong for digital signatures. I would not recommend a hash function not explicitly designed to be cryptographically strong, since they do not produce such a small digest as crypto hashes for a comparable level of resistance to collisions. By collision I mean two different files produce the same hash. MD5 is still very good for file content change monitoring - given its high sped and small digest size. It is the fastest hash function available. You can also find a fast MD5 implementation in assembly, for example from OpenSSL or from https://www.nayuki.io/page/fast-md5-hash-implementation-in-x86-assembly or http://blog.bfitz.us/?p=827

这篇关于在Web服务器中实现HTTP ETag的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆