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/Policy
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
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
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