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 18:54:42 GMT

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


Mime
View raw message