On Tue, 2004-08-17 at 19:04, Matthew Beermann wrote:
> Yes indeed! I found the problem; one of Slide's subclasses assumed that if
> you had credentials you wanted preemptive authentication turned on, and did
> so. I don't think that behavior is correct, and I sent a note to the Slide
> developers. On to the next problem!
>
> I spoke too soon when I said that everything works fine now. For any but the
> smallest files, HttpClient times out while waiting for the 100 Continue
> response from the server. A log is attached; they all look like this. If I
> had to guess, I would speculate that IIS is preallocating a file to receive
> the PUT data.
Matthew,
I seriously doubt that it should take so long to preallocate resources
for a 118K file. Usually if the expect-continue handshake is properly
implemented it takes just a few milliseconds for the server to respond
with the status code 100 (continue).
> In any event, the timeout of three seconds
> (RESPONSE_WAIT_TIME_MS) is apparently a hardcoded constant and cannot be
> changed. So what's a boy to do?
>
This constant is hardwired because up to now there's been no compelling
reason to parameterize it. The handshake either works, and then it takes
just a few millisecond pause, or it does not, and then it should be
deactivated.
Are you by any chance using SSL?
Oleg
>
> --Matthew Beermann
>
> ----- Original Message -----
> From: "Adrian Sutton" <[EMAIL PROTECTED]>
> To: "Jakarta Commons Users List" <[EMAIL PROTECTED]>
> Sent: Monday, August 16, 2004 4:04 PM
> Subject: RE: [HttpClient] Problems with PUT and NTLM
>
>
> Hi all,
>
> Slide uses a subclass of HttpState as I recall. The subclass obviously
> has:
>
> public boolean isAuthenticationPreemtive() {
> return true;
> }
>
> which would explain the behaviour you're seeing.
>
> Regards,
>
> Adrian Sutton.
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 17 August 2004 7:02 AM
> To: Jakarta Commons Users List
> Subject: Re: [HttpClient] Problems with PUT and NTLM
>
> client.getState().setAuthenticationPreemptive(false);
> > System.out.println(client.getState().isAuthenticationPreemptive());
> >
> > ...and got back "true", which confuses me completely. Does this not
> work the
> > way I think it does? I'd really like to ditch the wasted Basic:
> attempts.
>
> Matthew,
>
> Certainly this is not the way it is meant to be
>
> I am not sure if [Slide] uses a stock version of HttpClient or a forked
> one, but I know for a fact that in the stock version the preemptive
> authentication is disabled per default. When not explicitly turned on
> the preemptive authentication is not used
>
> Moreover, here's the verbatim copy of the
> HttpState#*AuthenticationPreemptive methods implementation.
>
> public void setAuthenticationPreemptive(boolean value) {
> this.preemptive = value;
> }
>
>
> public boolean isAuthenticationPreemptive() {
> return this.preemptive;
> }
>
> I just do not see how what you are saying is possible if the source code
> has not been tampered with.
>
> Try replacing the jar that comes with [Slide] with the latest stable
> release of HttpClient (version 2.0.1 as of writing) and see if that
> makes any difference
>
> Oleg
>
>
> On Mon, 2004-08-16 at 22:02, Matthew Beermann wrote:
> > A full log is attached. Turning on the expect-continue handshake does
> indeed
> > solve the problem (as seen in log #2). However, I still have a
> question
> > after looking at the logs: I tried putting these two lines one right
> after
> > the other:
> >
> > client.getState().setAuthenticationPreemptive(false);
> > System.out.println(client.getState().isAuthenticationPreemptive());
> >
> > ...and got back "true", which confuses me completely. Does this not
> work the
> > way I think it does? I'd really like to ditch the wasted Basic:
> attempts.
> >
> > --Matthew Beermann
> >
> > ----- Original Message -----
> > From: "Oleg Kalnichevski" <[EMAIL PROTECTED]>
> > To: "Jakarta Commons Users List" <[EMAIL PROTECTED]>
> > Sent: Friday, August 13, 2004 5:11 PM
> > Subject: Re: [HttpClient] Problems with PUT and NTLM
> >
> >
> > > Matthew,
> > >
> > > I missed the fact that the server reported a 500 error, which
> actually
> > > indicates an internal server error rather than an authentication
> error.
> > > Still, the 'expect-continue' handshake may be worth a try
> > >
> > > If Slide exposes the underlying HTTP PUT method you can activate the
> > > 'expect-continue' handshake by calling
> > >
> > > httpput.setUseExpectHeader(true);
> > >
> > > For details see
> > >
> > >
> http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/
> httpclient/methods/ExpectContinueMethod.html#setUseExpectHeader(boolean)
> > >
> > > You may also consider testing that HTTP PUT method using just plain
> > > HttpClient with the wirelog turned on in order to get more details
> on
> > > what is going on under the hood
> > >
> > > http://jakarta.apache.org/commons/httpclient/logging.html
> > >
> > > Hope this helps
> > >
> > > Oleg
> > >
> > >
> > > On Fri, 2004-08-13 at 23:45, Matthew Beermann wrote:
> > >> I'm trying to do a PUT with NTLM turned on, and it fails on a 500
> > >> error from the server, which in turn causes the console to report a
> > >> "Unbuffered entity enclosing request can not be repeated" error.
> Other
> > >> commands though, like PROPFIND and MKCOL, go through the
> > >> authentication steps and work perfectly. I've attached a log
> showing
> > >> the client/server conversation.
> > >>
> > >> OlegK suggested that I should activate the expect-continue
> handshake
> > >> on the HttpClient, which might fix my problems, but I'm afraid I
> > >> cannot figure out for the life of me how to do so. I should mention
> > >> that I'm working with HttpClient through Slide, and as such, I'm
> not
> > >> interfacing with HttpClient directly. (Which is to say, the Slide
> > >> library is creating PutMethod instances, not me.)
> > >>
> > >> --Matthew Beermann
> > >>
> > >>
> ______________________________________________________________________
> > >>
> ---------------------------------------------------------------------
> > >> 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]
