[
https://issues.apache.org/jira/browse/CXF-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695054#comment-14695054
]
Sergey Beryozkin commented on CXF-6528:
---------------------------------------
What exactly is the problem with registering a response filter with CXFRS ? It
has to be registered in cxfrs:providers. Or why not register with Camel a Date
to String type converter ?
I'm not sure it is a CXF issue at all, it is a Camel CXFRS issue, because in
standalone CXF or even with Camel CXFRS where CXF AbstractHttpDestination is
used, it will be converted properly at the CXF transport level when the headers
are written out.
I'm not sure about the extension approach. There are 3 exposure points of
response headers to the custom JAX-RS 2.0 code where they can be modified via
Map: ContainerResponseFilter, WriterInterceptor, MessageBodyWriter. So after a
call to each of those filters returns we'd need to iterate over the map values
and clone all Date again. I feel that doing it not because it does not work in
CXF but at the external integration point, is not exactly right. We'd do it in
CXF so that at Camel level one can avoid registering a Camel specific solution,
such as HttpTypeConverter.
I need to think more about it but at this point I feel I'd rather have a
generic fix at CXFRS level in a case of a non-CXF transport being used, before
the headers are exposed to that non-CXF transport, or provide
HttpDateTypeConverter
> JAX-RS "lastModified" generates timestamp with non-standard format
> ------------------------------------------------------------------
>
> Key: CXF-6528
> URL: https://issues.apache.org/jira/browse/CXF-6528
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.0.0-milestone2
> Environment: ServiceMix 5.4.0
> Reporter: metatech
>
> In CXF 3.x (since CXF-5007), the date format has changed in the
> "Last-Modified" HTTP header generated by JAX-RS.
> In class org.apache.cxf.jaxrs.impl.ResponseBuilderImpl, the method
> "lastModified()" does not call the "toHttpDate" anymore.
> The format is now the default format used when calling "toString" on the date
> object.
> This format is not one of the 3 allowed by the HTTP specification (RFC2616,
> section 3.3.1).
> For instance, an HTTPClient will reject this date format :
> ====================
> Wrong date format for date Wed Aug 12 08:18:54 CEST 2015
> org.apache.commons.httpclient.util.DateParseException: Unable to parse the
> date Wed Aug 12 08:18:54 CEST 2015
> at
> org.apache.commons.httpclient.util.DateUtil.parseDate(DateUtil.java:170)
> at
> org.apache.commons.httpclient.util.DateUtil.parseDate(DateUtil.java:94)
> ====================
> Can you please restore the date conversion ?
> Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
