Currently Tomcat 9 generates ETag like W/"1047-1578315296666" i.e. Weak"Size-MTime in Milliseconds". This is incorrect ETag because it should be strong as for a static file i.e. octal compatibility. Also to make ETag working for load balancing between Tomcat and Nginx we need to change format to "hex(MTime in seconds)-hex(Size)" e.g. "5e132e20-417". Nginx is not configurable but ether Tomcat is not. In the same time Nginx is more widely used while Tomcat returns incorrect ETag. See the W3C discussion for details https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0041.html I created a PR with the fix https://github.com/apache/tomcat/pull/324
1) You are combining two different things in a single change request, this is unwise. 2) It's not a "W3C" discussion; it's the IETF HTTP WG mailing list (which just happens to use a W3C list for historic reasons). 3) What exactly is "incorrect" about the current format? 4) The proposed format appears fragile to me as it assumes that a file system based resource will not change more than once per second.
3) What exactly is "incorrect" about the current format? Weak ETag means that server tells to client that the resource can't be octal compatible. The client MAY decide not to send Range requests to download part of the resource. For file resources like a video file this may lead to always re-downloading when user makes seek in player. 4) it assumes that a file system based resource will not change more than once per second. It assumes that during a second file will not be: * changed but mod time is remain the at same second * changed but it's size is the same * downloaded by a client and it requested the same resource again. Possibility of such event is extremely small and probably client even if performs so many consequent requests then it should mean: * client is fine to receive a stale data (it will re-request the resource anyway in next second) * client have a bug Client can just not send the If-None-Match header. While the Weak ETag is kind of semantical bug the main purpose of the PR is to make Tomcat, Nginx and other servers be able to accept ETags from each other.
3) So the ETag is not incorrect, it just might be suboptimal. 4) I would think your chances of this getting accepted would be bigger if you left the default handling as is, and added a way to configure something else.
I also thought to make ETag configurable like in Apache HTTPD but in fact for clients this is still opaque value and the Nginx is not configurable anyway while Apache Htttpd can be configured to be compliant with Nginx. I'm asking for this because this is a real issue for me. I developing a new service (https://github.com/yurt-page coming soon) that will use several servers: * WiFi router with a small blog engine running on BusyBox httpd * Tomcat on PC with the same blog engine plus admin panel. When PC is online requests will be redirected from router to PC. * Front server with Nginx with basic WAF, cache offload and static IP (kind of Cloudflare). So here the problem with ETag is extremely important for success. BusyBox not even had support of ETag so I sent a patch to to them http://lists.busybox.net/pipermail/busybox/2020-July/088102.html And I'm pretty sure that I'm not the only one who needs the ETag format interop. BTW the new ETag format while generated at the same speed are 14 bytes long while old used 22. Seems like not a big deal but they are transmitted on each request.
The original request (to align with Nginx format) will not be implemented. The Default Servlet has been refactored to make it simpler for users to provide a custom entity-tag of they wish.