cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Freeman Fang (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CXF-4844) Response header Content-type not recognized for asynchronous soap/http
Date Wed, 20 Mar 2013 07:45:16 GMT

     [ https://issues.apache.org/jira/browse/CXF-4844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Freeman Fang resolved CXF-4844.
-------------------------------

       Resolution: Fixed
    Fix Version/s: 2.7.4
                   2.8.0

commit fix
http://svn.apache.org/r1458659 for trunk
http://svn.apache.org/r1458664 for 2.7.x branch
                
> Response header Content-type not recognized for asynchronous soap/http
> ----------------------------------------------------------------------
>
>                 Key: CXF-4844
>                 URL: https://issues.apache.org/jira/browse/CXF-4844
>             Project: CXF
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 2.7.3
>         Environment: any
>            Reporter: Piotr Smolinski
>            Assignee: Freeman Fang
>             Fix For: 2.8.0, 2.7.4
>
>
> I've tried using asynchronous http webservices implementation. The test failed with NullPointerException:
> {code}
> java.lang.NullPointerException
> 	at org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:59)
> 	at org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:37)
> 	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
> 	at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:782)
> 	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1592)
> 	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:1123)
> 	at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:426)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 	at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:351)
> 	at java.lang.Thread.run(Thread.java:722)
> {code}
> The test however succeeded with synchronous call. After some investigation I realized
that the issue is missing Content-Type value which prevented StaxInInterceptor from injecting
the reader.
> The problem was caused by different code handling headers parsing for synchronous and
asynchronous calls:
> * URLConnectionHTTPConduit$URLConnectionWrappedOutputStream#updateResponseHeaders
> * AsyncHTTPConduit$AsyncWrappedOutputStream#updateResponseHeaders
> The first one gets Content Type from from connection. The latter one does interpret headers
and compare them (case-sensitive) against 'Content-Type' string. In the service I tested,
the server generates however 'Content-type' (which is still valid for RFC2616, 4.2 Message
Headers).
> The simplest solution is to fix AsyncWrappedOutputStream#readHeaders and replace "Content-Type".equals
with "Content-Type".equalsIgnoreCase 
> Thanks,
> Piotr

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message