cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-6528) JAX-RS "lastModified" generates timestamp with non-standard format
Date Thu, 13 Aug 2015 10:51:45 GMT

    [ 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)

Mime
View raw message