https://issues.apache.org/bugzilla/show_bug.cgi?id=54087
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
There is a grey(ish) area here.
SRV.3.4 states "If the getDateHeader method cannot translate the header to a
Date object, an IllegalArgumentException is thrown"
RFC2616-3.3.1 states "Recipients of date values are encouraged to be robust in
accepting date values". I take 'robust' in this case to mean tolerant rather
than strict. It could be read as either.
RFC2616-14.25.a as already quoted
Together, these suggest that Tomcat should try and parse the header regardless
of the format and if it can't parse it ignore it if the header is an
"If-Modified-Since" header.
When processing the If-Modified-Since header in the DefaultServlet, Tomcat does
follow RFC2616-14.25.a and effectively ignores the header.
The Javadoc for getDateHeader() states that "returns ... -1 if the named header
was not included with the request". That is the only circumstance in which -1
is a permitted return value so if the header is present but in the wrong format
Tomcat's only options are a) throw an IAE, b) parse it anyway. The problem with
b) is that Tomcat would have to guess what the invalid format was. That is
easier said than done. Therefore, all Tomcat can realistically do here is throw
IAE.
That, therefore, passes responsibility for adhering to RFC2616-14.25.a to
whatever code is calling getDateHeader(). In this case the application; making
it an application issue not a Tomcat one.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
