Re: Having some problems with "expect 100 continue"

Thu, 15 Jul 2004 15:03:21 -0700 

Oleg,

I cannot get the wire trace to work. I set the following properties in my java app, but I only get the INFO messages.

System.setProperty("org.apache.commons.logging.Log", "org.apache.commons.logging.impl.SimpleLog");
System.setProperty("org.apache.commons.logging.simplelog.showdatetime", "true");
System.setProperty("org.apache.commons.logging.simplelog.log.httpclient. wire", "debug");
System.setProperty("org.apache.commons.logging.simplelog.log.org.apache. commons.httpclient", "debug");

However, maybe this will help. I can put a small text file with no problems (although a 1 char file doesn't work). The problem I have is with putting a 1MB mpg file. I get the following messages then it appears to hang:

Jul 15, 2004 2:48:44 PM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme
INFO: digest authentication scheme selected
Jul 15, 2004 2:48:47 PM org.apache.commons.httpclient.HttpMethodBase writeRequest
INFO: 100 (continue) read timeout. Resume sending the request

Here's the wire trace (captured via tcpflow):

017.207.015.182.51117-017.207.015.236.02150: PUT /jentest1/Pictures/martin_crashTest3.mpg HTTP/1.1
User-Agent: Jakarta Commons-HttpClient/3.0-alpha1
Host: 17.207.15.236:2150
Expect: 100-continue
Content-Length: 941220


017.207.015.236.02150-017.207.015.182.51117: HTTP/1.1 401 Unauthorized
Server: AppleDotMacServer
X-Responding-Server: qa2-webdav03-qfe0
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
WWW-Authenticate: Basic realm="idisk.mac.com"
WWW-Authenticate: Digest realm="idisk.mac.com", qop="auth", nonce="12c55e49b83f4c39e0918155b5a2dd28", opaque="eb7ff29a0f14ddfa49f3f7880010b08a"
Content-Type: text/plain
Content-Length: 23
Date: Thu, 15 Jul 2004 21:47:39 GMT
Server: Apache Coyote/1.0


017.207.015.236.02150-017.207.015.182.51117: AUTHORIZATION_REQUIRED

017.207.015.182.51117-017.207.015.236.02150: PUT /jentest1/Pictures/martin_crashTest3.mpg HTTP/1.1
User-Agent: Jakarta Commons-HttpClient/3.0-alpha1
Expect: 100-continue
Content-Length: 941220
Authorization: Digest username="jentest1", realm="idisk.mac.com", nonce="12c55e49b83f4c39e0918155b5a2dd28", uri="/jentest1/Pictures/martin_crashTest3.mpg", response="a31a69f2e53b4b0afecf44904e952cca", qop="auth", nc=00000001, cnonce="214d593beae47a6bc701094207c8ab31", opaque="eb7ff29a0f14ddfa49f3f7880010b08a"
Host: 17.207.15.236:2150


017.207.015.182.51117-017.207.015.236.02150: ....!................................................................... ........................................................................ ....................
[content omitted]

By the way, I am running this on a Mac OS X system.

Thanks
Jen

On Jul 15, 2004, at 12:16 PM, Oleg Kalnichevski wrote:

Jennifer,

I ran a small test app that posted a 3 byte request to the local Tomcat
4.1.29 with 'expect: continue' handshake on. Everything seems fine as
far as I can tell

====================================================================
DEBUG] HttpClient - -Java version: 1.4.2
[DEBUG] HttpClient - -Java vendor: Sun Microsystems Inc.
...
[DEBUG] HttpClient - -Operating system name: Linux
[DEBUG] HttpClient - -Operating system architecture: i386
[DEBUG] HttpClient - -Operating system version: 2.6.6-1.435smp
...
[DEBUG] DefaultHttpParams - -Set parameter http.protocol.expect-continue
= true
[DEBUG] header - ->> "POST /httpclienttest/body HTTP/1.1[\r][\n]"
[DEBUG] HttpMethodBase - -Adding Host request header
[DEBUG] header - ->> "User-Agent: Jakarta
Commons-HttpClient/3.0-alpha1[\r][\n]"
[DEBUG] header - ->> "Host: localhost:8080[\r][\n]"
[DEBUG] header - ->> "Expect: 100-continue[\r][\n]"
[DEBUG] header - ->> "Content-Length: 3[\r][\n]"
[DEBUG] header - ->> "[\r][\n]"
[DEBUG] header - -<< "HTTP/1.1 100 Continue[\r][\n]"
[DEBUG] HttpMethodBase - -OK to continue received
[DEBUG] EntityEnclosingMethod - -Request body sent
[DEBUG] header - -<< "HTTP/1.1 200 OK[\r][\n]"
[DEBUG] header - -<< "Content-Type: text/html[\r][\n]"
[DEBUG] header - -<< "Date: Thu, 15 Jul 2004 19:08:04 GMT[\r][\n]"
[DEBUG] header - -<< "Server: Apache Tomcat/4.1.29 (HTTP/1.1
Connector)[\r][\n]"
[DEBUG] header - -<< "Transfer-Encoding: chunked[\r][\n]"
HTTP/1.1 200 OK
[DEBUG] HttpMethodBase - -Resorting to protocol version default close
connection policy
[DEBUG] HttpMethodBase - -Should NOT close connection, using HTTP/1.1
[DEBUG] HttpConnection - -Releasing connection back to connection
manager.
====================================================================

Here's the test app source

====================================================================
HttpClient agent = new HttpClient();
PostMethod httppost =
new PostMethod("http://localhost:8080/httpclienttest/body";);
httppost.getParams().
setParameter(HttpMethodParams.USE_EXPECT_CONTINUE, new Boolean(true));
httppost.setRequestEntity(new StringRequestEntity("1\r\n"));
try {
agent.executeMethod(httppost);
} finally {
httppost.releaseConnection();
}
System.out.println(httppost.getStatusLine());
====================================================================

I am afraid I'll need more details about your local execution
environment in order to be any further help. A wirelog would be a good
start

Cheers,

Oleg



On Thu, 2004-07-15 at 20:54, Jennifer Ward wrote: 
On Jul 15, 2004, at 11:02 AM, Oleg Kalnichevski wrote:

Jennifer,

What is the version of Tomcat you are using? Even though, as Eric
pointed out, Tomcat does not fully support the expect/continue
handshake, last time I checked it at least did not produce any nasty
side effects. Please let me know the exact version of Tomcat I'll
re-test HttpClient against that particular version.


Were using 4.1.27, but moving soon to 4.1.30.


The complete wire/debug log produced with the latest HttpClient CVS
snapshot might also be of help


I've already rebuilt my client using HttpClient 2.0. I'll rebuild it
using the latest snapshot, rerun and grab the log.

Thanks
Jen


Oleg

On Thu, 2004-07-15 at 18:57, Jennifer Ward wrote:
On Jul 15, 2004, at 1:09 AM, Kalnichevski, Oleg wrote:

(1) Are you using SSL? 

No

(2) What's the JRE version you are using? 

Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.2_03-117.1)

(3) What web server you are targeting? 

We are using Apache Tomcat with Slide for WebDAV support.


(4) Are you going through a proxy?

I'm hitting the server directly at the moment. I will be going through
a proxy eventually.

Jen



Oleg

-----Original Message-----
From: Jennifer Ward [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 15, 2004 1:49
To: Commons HttpClient Project
Subject: Having some problems with "expect 100 continue"


All,

I'm now calling setUseExpectHeader(true) for my putMethod. However,
I'm
running into a few problems.

First, when putting a 1 character text file (Content-Length: 3) it
doesn't authorize and eventually I get the 'Maximum redirects (100)
exceeded' exception.

If I take a slightly larger text file (Content-Length: 7), then all
is
fine. However, I do get the INFO message:

Jul 14, 2004 4:40:33 PM org.apache.commons.httpclient.HttpMethodBase
processRequest
INFO: Recoverable exception caught when processing request

If I try to put a 1MB mpg file, the request appears to hang with:

Jul 14, 2004 4:41:44 PM org.apache.commons.httpclient.HttpMethodBase
writeRequest
INFO: 100 (continue) read timeout. Resume sending the request

Any suggestions? I did try this with the latest build of HttpClient
also and had similar results.

Thanks,
Jen



On Jul 14, 2004, at 11:43 AM, Oleg Kalnichevski wrote:

On Wed, 2004-07-14 at 18:10, Jennifer Ward wrote: 
On Jul 13, 2004, at 8:03 PM, Michael Becke wrote:


Another way to handle this problem is to use the "expect 100
continue"
feature of HTTP. This feature is disabled in HttpClient by
default,
as only a few servers support it correctly. You can re-enable it
by
calling setUseExpectHeader(true) on the post method.

Yes, Oleg mentioned this a few days ago. It sounds like this
feature
still causes the request to get sent twice (even though the request
body will not get sent if the server cannot receive it). I was
hoping
for a way to send each request only once (with the correct auth
header
the first time). 

Jennifer,

This can be done if you are prepared to handle the entire
authentication
process manually (actually with HttpClient 3.0 it can be done quite
easily). The question is if it is really worth the trouble. It is
important to understand Digest authentication scheme is more secure
primarily because it involves frequent challenge-response exchanges.
The
server generates a nonce which is used by the HTTP clients to
produce
the password digest. If the server is configured to change the nonce
too
often, that would basically defeat any sort of preemptive
authentication
mechanism, in the worst case rendering it even less efficient than
'expect-continue' handshake. If the server is configured to keep the
nonce for too long, that would inevitably make Digest authentication
less secure. It is not impossible to strike a balance between
efficiency
and security. The question is whether the performance gains really
justify additional complexity

Oleg


I'm not having much luck with that though, so I may
end up using the "expect 100 continue" feature after all.

Thanks
Jen


----------------------------------------------------------------- --
--
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



------------------------------------------------------------------ --
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



------------------------------------------------------------------- --
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]


******************************************************************* **
**
****************************
The information in this email is confidential and may be legally
privileged. Access to this email by anyone other than the intended
addressee is unauthorized. If you are not the intended recipient of
this message, any review, disclosure, copying, distribution,
retention, or any action taken or omitted to be taken in reliance on
it is prohibited and may be unlawful. If you are not the intended
recipient, please reply to or forward a copy of this message to the
sender and delete the message, any attachments, and any copies
thereof
from your system.
******************************************************************* **
**
****************************

------------------------------------------------------------------- --
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



-------------------------------------------------------------------- -
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to