We are not sending the correct Last-Modified header when serving files from tlwebaccess and tlwebadm. The standard says it should be sent in the rfc822 format: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified https://tools.ietf.org/html/rfc7231#section-7.1.1.1 However we are sending the output of ctime(), which uses a different format and is using local time, not UTC. Note that HTTP (but not MDN) specifies that the format that ctime() uses should be tolerated, but it must be UTC. So we are currently pushing the boundaries of what is allowed. Practical effects are currently unknown. Worst case scenario should be that caching doesn't work correctly and browsers fetch resources needlessly.
Firefox oddly enough sends the same string back to us in the If-Modified-Since header, so it is unclear if it doesn't parse the string or if it somehow remembers we are using a deprecated format. This should break though as we assume that If-Modified-Since follows rfc822. Fortunately Python's rfc822.parsedate() tolerates some other formats, so it works anyway. It is untested if both deprecated formats specified by HTTP are supported though.
Chrome's behaviour is unclear at this point. It is caching things at least, but I'm unable to prod it into sending any If-Modified-Since headers.
(In reply to Pierre Ossman from comment #2) > Chrome's behaviour is unclear at this point. It is caching things at least, > but I'm unable to prod it into sending any If-Modified-Since headers. Waiting a while makes Chrome do a request with the header, and it seems to follow the same behaviour as Firefox (using the same format it got from the server).
Fixed now. Can see the correct date format in the sent headers. Tested using Firefox and Chrome.
Date format looks good in both Firefox 80 and Chrome 85. Looked at both webaccess and webadmin pages.
