[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123
Github user rainerjung commented on the issue: https://github.com/apache/tomcat/pull/115 Note that although the RFC demands to handle an invalid Expires header (like Expires: 0) like one with a timestamp in the past, I coincidentally ran into a problem yesterday, where the Apache web server with mod_cache only complies to this in the default case. By default in both cases content is not cached. But in the case of a valif timestamp in the past, more rules apply, like being able to force caching by configuration and also evaluating Cache-Control max-age and s-maxage. In the invalid Expires value case, the decision to not cache currently happens unconditionally. I applied a patch to the trunk of the Apache web server yesterday and proposed it for 2.4, but it might serve as an example, why an explicit timestamp in the past might be slightly more robust (while being a bit more expensive) then just "Expires: 0" or any other invalid value. --- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123
Github user rainerjung commented on the issue: https://github.com/apache/tomcat/pull/115 @michael-o APR_DATE_BAD: the date string was null, or unparsable or the parsed date does not exist. A date in the past would not result in APR_DATE_BAD. A timestamp before the unix epoch should be fine as well, but I didn't check that. Concerning "Expires: 1970 ...[a valid formatted timestamp]" versus "Expires: 0" I might not understand your question. First "Expires: 0" is not valid, accoring to the HTTP RFC it is invalid, but the RFC defines how a client should behave when it notices such an invalid value. The RFC demands a formatted timestamp string as the value of the Expires header. Only such are valid due to the syntax of the header in RFC 7234: Expires = HTTP-date HTTP-date = and in RFC 7231 HTTP-date= IMF-fixdate / obs-date and then lots of additional definitions making clear, that only formatted absolute timestamps in a few explicitly defined formats are allowed. Not allowed (invalid) are simple numerical offsets like "0". BUT: RFC 7234 states that any invalid header must be handled like a vlid header with a timestamp in the past. My web server example shows, that not all products might interprete this sentence to the full extreme. Configuration options that for instance control the behavior of a shared cache in front of Tomcat might allow admins to overwrite caching decisions. In this case it could make a difference, whether the cache sees a valid Expires with a time in the past or an invalid one. As an example Apache httpd 2.4. I dont want to argue whether this is RFC compliant (because the config option operates explicitly outside of the RFC) and I hold the opinion, that the code of the cache should be changed to coincide more with that aspect of the RFC, but it was simply meant as an example why not relying too much on the RFC sentence, that an invalid Expires will be handled like on the past might lead to less runtime problems. --- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123
Github user rainerjung commented on the issue: https://github.com/apache/tomcat/pull/115 @michael-o IMHO because an invalid header value will push most parsing code to the error handling code path. And only by additional rules should that code handle it like a valid header in the past. Your chances of client software compatibility are higher than by sending an invalid value. This of course is not an especially strong argument. I simply wanted to provide a real-world example, where it currently does make a difference. --- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] tomcat issue #120: fix -Djava.security.policy setting
Github user rainerjung commented on the issue: https://github.com/apache/tomcat/pull/120 I think the double "==" here is itentional. For the meaning of the double equals sign see e.g. https://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html (look for ==). Keeping it open for others to chime in. --- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
