[
https://issues.apache.org/jira/browse/HTTPCLIENT-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988429#action_12988429
]
Oleg Kalnichevski commented on HTTPCLIENT-1048:
-----------------------------------------------
>> "POST /ExpectTest/j_security_check HTTP/1.1[EOL]"
>> "Content-Length: 35[EOL]"
>> "Content-Type: application/x-www-form-urlencoded; charset=ISO-8859-1[EOL]"
>> "Host: localhost:8080[EOL]"
>> "Connection: Keep-Alive[EOL]"
>> "User-Agent: Apache-HttpClient/4.0.3 (java 1.5)[EOL]"
>> "Expect: 100-Continue[EOL]"
>> "Cookie: JSESSIONID=F1A440D77108B972C472B368A7695FA5[EOL]"
>> "Cookie2: $Version=1[EOL]"
>> "[EOL]"
>> "j_username=tomcat&j_password=tomcat"
<< "HTTP/1.1 302 Moved Temporarily[EOL]"
<< "Server: Apache-Coyote/1.1[EOL]"
<< "Location: http://localhost:8080/ExpectTest/[EOL]";
<< "Content-Length: 0[EOL]"
<< "Date: Sat, 29 Jan 2011 10:03:17 GMT[EOL]"
<< "[EOL]"
As you can see from this snippet, both the agent and the origin server use
HTTP/1.1 protocol versions, and therefore both are expected to comply with the
requirements of section 8.2.3 'Use of the 100 (Continue) Status', RFC 2616
---
Requirements for HTTP/1.1 origin servers:
- Upon receiving a request which includes an Expect request-header
field with the "100-continue" expectation, an origin server MUST
either respond with 100 (Continue) status and continue to read
from the input stream, or respond with a final status code. The
origin server MUST NOT wait for the request body before sending
the 100 (Continue) response.
---
As far as I can tell the origin server fails to comply with this requirement.
The delay of two seconds is caused by HttpClient waiting for the origin server
to respond with a 100 status or a final response such as status 417.
---
Because of the presence of older implementations, the protocol allows
ambiguous situations in which a client may send "Expect: 100-
continue" without receiving either a 417 (Expectation Failed) status
or a 100 (Continue) status. Therefore, when a client sends this
header field to an origin server (possibly via a proxy) from which it
has never seen a 100 (Continue) status, the client SHOULD NOT wait
for an indefinite period before sending the request body.
---
> PostMethod very slow 'out of the box' for /j_security_check
> -----------------------------------------------------------
>
> Key: HTTPCLIENT-1048
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1048
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 4.0.3
> Environment: Java 6, Tomcat 6, JBoss 5.1
> Reporter: Kennard Consulting
> Attachments: ExpectTest.war, wire.log
>
>
> First, thanks for an awesome piece of work in HttpClient. I use it every day
> and it is very useful to me.
> HttpClient's default settings include adding an...
> Expect: 100-continue
> ...header to every PostMethod. This seems to interact poorly with Tomcat's
> (and possibly other Java EE containers) FormAuthenticator. I tested on both
> Tomcat 6 and JBoss 5.1.0 (which I believe uses a fork of Tomcat). Testing
> both with/without the 'Expect' header I see '/j_security_check' login times
> of:
> With Expect header: 2012ms
> Without Expect header: 8ms
> So the default is some 250x slower. This is without a database or any other
> complicating factors. It can make a dramatic difference if you are using
> HttpClient to simulate logging in and retrieving information.
> I include a test WAR. To deploy it:
> 1. Copy into /webapps
> 2. Edit conf/tomcat-users.xml to enable the tomcat/tomcat username/password
> 3. Run Tomcat
> 4. Hit http://localhost:8080/ExpectTest
> 5. Log in as tomcat/tomcat
> 6. Hit 'Start Test'
> The issue can be worked around by removing the RequestExpectContinue
> interceptor, but it takes a lot of digging through code to realise this.
> Otherwise you may simply conclude 'HttpClient is slow'.
> According to the HTTP spec
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3), the 100
> header "allows a client that is sending a request message with a request body
> to determine if the origin server is willing to accept the request (based on
> the request headers) before the client sends the request body. In some cases,
> it might either be inappropriate or highly inefficient for the client to send
> the body if the server will reject the message without looking at the body".
> So perhaps this setting should only apply for 'large' POST bodies, not for
> simple 'j_username=Foo&j_password=Bar' bodies?
> Regards,
> Richard
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
