hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jennifer Ward <jennif...@apple.com>
Subject Re: Having some problems with "expect 100 continue"
Date Thu, 15 Jul 2004 22:01:48 GMT
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:jenniferw@apple.com]
>>>>> 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:
>>>>>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>>>>> For additional commands, e-mail:
>>>>>>> commons-httpclient-dev-help@jakarta.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------

>>>>>> --
>>>>>> -
>>>>>> To unsubscribe, e-mail:
>>>>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail:
>>>>>> commons-httpclient-dev-help@jakarta.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------- 
>>>>> --
>>>>> To unsubscribe, e-mail:
>>>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail:
>>>>> commons-httpclient-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>> ******************************************************************* 
>>>>> **
>>>>> **
>>>>> ****************************
>>>>> 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:
>>>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail:
>>>>> commons-httpclient-dev-help@jakarta.apache.org
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------- 
>>>> -
>>>> To unsubscribe, e-mail:
>>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail:
>>>> commons-httpclient-dev-help@jakarta.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> commons-httpclient-dev-help@jakarta.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:  
>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:  
>> commons-httpclient-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:  
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:  
> commons-httpclient-dev-help@jakarta.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message