Having some problems with "expect 100 continue"

[Jennifer Ward <je...@apple.com>]

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