[
https://issues.apache.org/jira/browse/HTTPCLIENT-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988505#action_12988505
]
Kennard Consulting commented on HTTPCLIENT-1048:
------------------------------------------------
Okay opened: https://issues.apache.org/bugzilla/show_bug.cgi?id=50689
Thanks,
Richard.
> 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]
