cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "metatech (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CXF-6528) JAX-RS "lastModified" generates timestamp with non-standard format
Date Thu, 13 Aug 2015 12:56:46 GMT

    [ https://issues.apache.org/jira/browse/CXF-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695169#comment-14695169
] 

metatech edited comment on CXF-6528 at 8/13/15 12:56 PM:
---------------------------------------------------------

Sergey.  Here are my reactions to your suggested solutions : 
1. Registering a response filter : this filter has to be declared in all CXF RS applications
using "lastModified" and "expires" methods.  This sounds like internals of Camel+CXF which
are pushed to the application developer's responsiblity. I would be nice if Camel+CXF would
handle it automatically
2. Registering a custom Date to String converter in Camel.  This converter is placed at a
very general place.  What if some existing applications using some other Camel component which
are relying on the fact that the current conversion outputs a date with the same format as
the "Date.toString()".  Wouldn't this break these applications ?
3. "Pre-conversion" before handling to non-CXF transport : it sounds good, but will these
conversions only apply to the "Last-Modified" and "Expires" HTTP headers, or also to all other
dates ?
Thanks.


was (Author: metatech):
Sergey.  Here are my reactions to your suggested solutions : 
1. Registering a response filter : this filter has to be declared in all CXF RS applications
using "lastModified" and "expires" methods.  This sounds like internals of Camel+CXF which
are pushed to the application developer's responsiblity. I would be nice if Camel+CXF would
handle it automatically
2. Registering a custom Date to String converter in Camel.  This converter is placed at a
very general place.  What is some existing applications using some other Camel component which
are relying on the fact that the current conversion outputs a date with the same format as
the "Date.toString()".  Wouldn't this break these applications ?
3. "Pre-conversion" before handling to non-CXF transport : it sounds good, but will these
conversions only apply to the "Last-Modified" and "Expires" HTTP headers, or also to all other
dates ?
Thanks.

> 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