[jira] [Created] (CXF-4844) Response header Content-type not recognized for asynchronous soap/http

["Piotr Smolinski (JIRA)" <ji...@apache.org>]

Piotr Smolinski created CXF-4844:
------------------------------------

             Summary: 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


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