Details
-
Bug
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
-
None
-
Platform Sprint 144
Description
In HSTTWO-3554 I made a fix to correctly parse the expires header because it was assumed to always be in RFC1123 date format. However this is only the case when the setDateHeader is invoked on a HstResponse. If setDateHeader is invoked directly on the backing HttpServletResponse, you get the long (ms since epoch) back (the container will later translate it to RFC1123)
Attachments
Issue Links
- is a result of
-
HSTTWO-3554 Honoring a TTL when that is set by an HstComponent
- Closed
- is cloned by
-
HSTTWO-3870 [Backport 4.0] Parsing of expires headers fails if expires is set directly on backing HttpServletResponse
- Closed
-
HSTTWO-3871 [Backport 3.2] Parsing of expires headers fails if expires is set directly on backing HttpServletResponse
- Closed