Issue link: https://read.uberflip.com/i/1146286
92 | Chapter 13: Rule 13: Configure ETags The ETag format for Apache 1.3 and 2.x is inode-size-timestamp. Inodes are used by filesystems to store information such as file type, owner, group, and access mode. Although a given file may reside in the same directory across multiple servers and have the same file size, permissions, timestamp, etc., its inode is different from one server to the next. IIS 5.0 and 6.0 have a similar issue with ETags. The format for ETags on IIS is Filetimestamp:ChangeNumber. ChangeNumber is a counter used to track configuration changes to IIS. It's unlikely that the ChangeNumber is the same across all IIS servers behind a web site. The end result is that ETags generated by Apache and IIS for the exact same compo- nent won't match from one server to another. If the ETags don't match, the user doesn't receive the small, fast 304 response that ETags were designed for; instead, they'll get a normal 200 response along with all the data for the component. If you host your web site on just one server, this isn't a problem, but if you use a cluster of servers, components have to be downloaded much more often than is required, which degrades performance. The unnecessary reloading of components also has a performance impact on your servers and increases your bandwidth costs. If you have n servers in your cluster in round-robin rotation, the probability that the ETag in the user's cache will match the server they land on next is 1/n. If you have 10 servers, the user has a 10% chance of getting the correct 304 response, leaving a 90% chance of getting a wasteful 200 response and full data download. This ETag issue also degrades the effectiveness of proxy caches. The ETag cached by users behind the proxy frequently won't match the ETag cached by the proxy, result- ing in unnecessary requests back to the origin server. Instead of one 304 response between the user and the proxy, there are two (slower, bigger) 200 responses: one from the origin server to the proxy, and another from the proxy to the user. The default format of ETags has also been cited as a possible security vulnerability. * It gets worse. The If-None-Match header takes precedence over If-Modified-Since. You might hope that if the ETags didn't match but the last-modified date was the same, a "304 Not Modified" response would be sent, but that's not the case. According to the HTTP/ 1.1 specification (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.4), if both of these headers are in the request, the origin server "MUST NOT return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in the request." It would actually be better if the If-None- Match header wasn't even there. That's the solution discussed in the next section. * See the "Apache http daemon file inode disclosure vulnerability" web article at http://www3.ca.com/ securityadvisor/vulninfo/vuln.aspx?ID=7196 for more information.