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]
