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 = <HTTP-date, see [RFC7231], Section 7.1.1.1>
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
