[
https://issues.apache.org/jira/browse/HTTPCLIENT-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kennard Consulting updated HTTPCLIENT-1048:
-------------------------------------------
Description:
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 the code to realise this.
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
was:
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 the code to realise this.
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' requests?
Regards,
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
>
>
> 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 the code to realise this.
> 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]
