[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
6:53 a.m.
[
https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin....
]
bene.net edited comment on WFLY-3560 at 9/22/14 7:52 AM:
---------------------------------------------------------
We got the same exception on a HTTP PUT:
{code}
Blocking request failed HttpServerExchange{ PUT
/veto-ifc/ifcv1/definitions/resource-versions/3083}: java.lang.IllegalStateException:
UT000004: getResponseChannel() has already been called
at
io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
...
{code}
In our case we use a .NET client to connect to a REST service deployed in WildFly
8.1.0.Final "Kenny".
The problem can be reproduces like this:
1. The .NET client does not send user credentials, but sends header "Expect:
100-continue" and HTTP content
2. Wildfly immediately returns HTTP/1.1 401 Unauthorized
3. Client sends content and ignores 401 Unauthorized
{code}
PUT /veto-ifc/ifcv1/definitions/resource-versions/3083 HTTP/1.1
Accept: application/xml
Content-Type: application/xml
Host: bchlap-11.head.de:8080
Content-Length: 112994
Expect: 100-continue
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Basic realm="VETO Interface"
X-Powered-By: Undertow/1
Server: WildFly/8
Content-Type: application/xml; charset=UTF-8
Content-Length: 409
Date: Mon, 22 Sep 2014 09:45:03 GMT
<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base-uri="http://bchlap-11.head.de:8080/veto-ifc/"
xsi:noNamespaceSchemaLocation="response.xsd">
<status>
<message key="ERROR_ACCESS_DENIED">
<param key="details" value="Authentication credentials are
required"/>
</message>
</status>
</response>
<resource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="resource.xsd">
<database-meta-data>
<meta-data group="VERSION" key="00-Basis"
value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="01-Activity"
value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="02-Activity_WithV1"
value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="UpgradeDbTool"
value="3.0.0-SNAPSHOT (n/a)" />
<meta-data group="VERSION" key="ImportExportTool"
value="3.0.0-SNAPSHOT (2014-09-22 11:10:22.692+0200)" />
</database-meta-data>
... more content ...
{code}
Our workaround is to use HttpWebRequest.PreAuthenticate Property in the client to avoid
401 Unauthorized.
http://msdn.microsoft.com/de-de/library/system.net.httpwebrequest.preauth...
I hope this information help to fix the issue.
Thanks a lot!
was (Author: bene.net):
We got the same exception on a HTTP PUT:
{code}
Blocking request failed HttpServerExchange{ PUT
/veto-ifc/ifcv1/definitions/resource-versions/3083}: java.lang.IllegalStateException:
UT000004: getResponseChannel() has already been called
at
io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
...
{/code}
In our case we use a .NET client to connect to a REST service deployed in WildFly
8.1.0.Final "Kenny".
The problem can be reproduces like this:
1. The .NET client does not send user credentials, but sends header "Expect:
100-continue" and HTTP content
2. Wildfly immediately returns HTTP/1.1 401 Unauthorized
3. Client sends content and ignores 401 Unauthorized
{code}
PUT /veto-ifc/ifcv1/definitions/resource-versions/3083 HTTP/1.1
Accept: application/xml
Content-Type: application/xml
Host: bchlap-11.head.de:8080
Content-Length: 112994
Expect: 100-continue
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Basic realm="VETO Interface"
X-Powered-By: Undertow/1
Server: WildFly/8
Content-Type: application/xml; charset=UTF-8
Content-Length: 409
Date: Mon, 22 Sep 2014 09:45:03 GMT
<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base-uri="http://bchlap-11.head.de:8080/veto-ifc/"
xsi:noNamespaceSchemaLocation="response.xsd">
<status>
<message key="ERROR_ACCESS_DENIED">
<param key="details" value="Authentication credentials are
required"/>
</message>
</status>
</response>
<resource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="resource.xsd">
<database-meta-data>
<meta-data group="VERSION" key="00-Basis"
value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="01-Activity"
value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="02-Activity_WithV1"
value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="UpgradeDbTool"
value="3.0.0-SNAPSHOT (n/a)" />
<meta-data group="VERSION" key="ImportExportTool"
value="3.0.0-SNAPSHOT (2014-09-22 11:10:22.692+0200)" />
</database-meta-data>
... more content ...
{/code}
Our workaround is to use HttpWebRequest.PreAuthenticate Property in the client to avoid
401 Unauthorized.
http://msdn.microsoft.com/de-de/library/system.net.httpwebrequest.preauth...
I hope this information help to fix the issue.
Thanks a lot!
Combination of HTTP Request Header "Connection:keep-alive"
and "Expect:100-conitnue" causes Wildfly undeploy apps
-----------------------------------------------------------------------------------------------------------------
Key: WFLY-3560
URL: https://issues.jboss.org/browse/WFLY-3560
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.0.0.Final, 8.1.0.Final
Reporter: Gary Yang
Assignee: Jason Greene
Issue is described in https://community.jboss.org/thread/242415
If client uses "Connection:keep-alive" and "Expect:100-continue" in
HTTP request header and send multiple requests, Wildfly (including 8.0.0 and 8.1.0) throws
following exception:
{noformat}
2014-06-29 11:12:14,721 ERROR [io.undertow.request] (default task-26) Blocking request
failed HttpServerExchange{ POST /enterprise/composite/postAndSend}:
java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at
io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
at
io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
at
org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
[xnio-api-3.2.0.Final.jar:3.2.0.Final]
at
io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
at
io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1897)
at org.xnio.channels.Channels.readBlocking(Channels.java:294)
[xnio-api-3.2.0.Final.jar:3.2.0.Final]
at
io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:138)
at
io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
at
io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:589)
at
io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
at
io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1363)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:183)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_55]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_55]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
{noformat}
If there are multiple users sending this kind of requests, Wildfly eventually undeploy
all applications.
Here is a test code using Apache HTTP client
{code:java}
HttpPost request = new HttpPost(serverURL);
for (int i=0; i<200; i++) {
StringEntity input = new StringEntity (payLoad);
input.setContentType("application/json");
request.setHeader("Connection", "keep-alive");
request.setHeader("Expect", "100-continue");
request.setEntity(input);
HttpResponse response = httpclient.execute(request);
HttpEntity entity = response.getEntity();
if (entity != null) {
System.out.println("Response content length: " +
entity.getContentLength());
}
EntityUtils.consume(entity);
if (entity != null) {
System.out.println("Response content length: " +
entity.getContentLength());
}
EntityUtils.consume(entity);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
3706
days inactive
3706
days old
0 comments
1 participants
participants (1)
-
bene.net (JIRA)