[
https://issues.apache.org/jira/browse/CXF-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897059#comment-17897059
]
Andriy Redko commented on CXF-9078:
-----------------------------------
Indeed the spec [1] is not strict on that but the general recommendation [1] is
that:
{quote}Although request message framing is independent of the method used,
content received in a GET request has no generally defined semantics, cannot
alter the meaning or target of the request, and might lead some implementations
to reject the request and close the connection because of its potential as a
request smuggling attack ([Section
11.2|https://www.rfc-editor.org/rfc/rfc9112#section-11.2] of
[[HTTP/1.1|https://www.rfc-editor.org/rfc/rfc9110.html#HTTP11]]). A client
SHOULD NOT generate content in a GET request unless it is made directly to an
origin server that has previously indicated, in or out of band, that such a
request has a purpose and will be adequately supported. An origin server SHOULD
NOT rely on private agreements to receive content, since participants in HTTP
communication are often unaware of intermediaries along the request chain.
{quote}
If I am not mistaken, the Apache HttpClient 4.x (I assume this is the
AsyncHTTPConduit impl referenced here) does not support payload by default.
[1] [https://www.rfc-editor.org/rfc/rfc9110.html#name-get]
> AsyncHTTPConduit.java causing NullPointerException when closing
> ---------------------------------------------------------------
>
> Key: CXF-9078
> URL: https://issues.apache.org/jira/browse/CXF-9078
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 4.0.5
> Reporter: Luke Xu
> Priority: Major
>
> When using HTTP GET action by either calling JAX-WS Dispatch invoke() or
> JAX-RS WebClient invoke()/async().method() with a dummy payload, the program
> always ends up with a NullPointerException.
> The typical stack flow could look like the following:
>
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.io.OutputStream.write(byte[], int, int)" because "<parameter1>" is null
> at java.base/java.io.ByteArrayOutputStream.writeTo(Unknown Source)
> at
> org.apache.cxf.io.CachedOutputStream.writeCacheTo(CachedOutputStream.java:317)
> at
> org.apache.cxf.transport.http.asyncclient.hc5.AsyncHTTPConduit$AsyncWrappedOutputStream.close(AsyncHTTPConduit.java:439)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:228)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:717)
> at
> org.apache.cxf.transport.http.HttpClientHTTPConduit.close(HttpClientHTTPConduit.java:249)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314)
> at org.apache.cxf.endpoint.ClientImpl.invokeWrapped(ClientImpl.java:349)
> at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:322) {code}
>
>
> By checking code around AsyncHTTPConduit.java:439, I would think
> handleHeadersTrustCaching() could have left _wrappedStream_ as _null_ for GET
> action, which eventually crashing the later _out.writeCacheTo(wrappedStream)._
>
> My local case seems to be OK after I override the class and put a check
> before _out.writeCacheTo(wrappedStream)._ But I'm no expert on the related
> modules. Please let me know if there are any other solutions.
>
> I know the issue won't be hit with JAX-RS client if GET is triggered with a
> null payload. But somehow in our usage, we can't totally ban GET for JAX-WS
> dispatch. So it's still a problem to us.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
