cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: PUT/POST with Auth Done Right(?)

From: Jamie Lokier <jamie_at_shareable.org>
Date: Tue, 9 Nov 2004 19:50:04 +0000

Daniel Stenberg wrote:
> >Well implemented HTTP servers implementing other auth types will send 401
> >without waiting, so the send-twice problem doesn't occur with them. So
> >there is no need for a special hack with them.
>
> Do we know for sure that Apache for example does this for Digest?

Apparently not. I was reading the code for Apache 1 and Apache 2 and
I think that Apache 1 did, but Apache 2 does not, however I can't
easily test Apache 1 right now.

I have tested Apache 2.0.40, and it waits for the whole request before
sending a 401 response, as well as unconditionally sending 100 Continue.

However, interesting news!

David's latest trace shows that IIS 6.0 *does* send 401 for NTLM auth
before receiving the request body. You can clearly see the 401 very
soon after the first request, with no 100 Continue of course. IE6
proceeds to send all of the request anyway, and continues to use the
same connection for the second and third requests.

So IIS 6.0 is doing something quite smart, but IE6 is not.

Exactly copying the behaviour of IE6 would work, but IE6 does not send
"Expect: 100-continue" and significantly it does not have a delay
waiting for "100 Continue" before sending the request body.

It's certainly within the spirit and letter of RFC2616 for a client to
abort when it has an error response and a large request body that
doesn't need to be sent. So I'd code that, then ask David to kindly
test that it does work with IIS 6.0. That's a much better strategy
than IE's.

> >By the way, what will you do if the server returns 401/407 to _this_
> >request? Couldn't that happen if a proxy demands authentication and then
> >the server does as well? Couldn't it even happen more times, if several
> >proxies demand authentication?
>
> You are right. If the proxy also demands auth we might in fact have to send
> the data three times! (We only support one proxy.)

The worst case is when a proxy does not maintain a one-to-one
relationship between it's upstream and downstream connections. Some
proxies don't support HTTP/1.1 at all; others are smart and have
different strategies for pooling upstream connections.

I expect NTLM-HTTP simply does not work over such proxies.

> >> Optionally, we keep the current approach if some option is set, since it
> >> seems to work fairly well for POST on most servers.
> >
> >I know real servers where that will fail with PUT. My own is one of them.
>
> Yes, in fact I doubt there is a single one that will work with HEAD/PUT.
> The case for HEAD/POST is much more likely to work.
>
> >It would be great if IIS 6 does the right thing and sends 401/407
> >immediately: then you can just tell people who don't like the send-twice
> >bandwidth wastage to upgrade IIS.
>
> I don't think it does. I don't remember the exact details, but if David
> can't provide one of his excellent logs for this case I think we can dig up
> some useful info from the list archives from the previous time we had to
> bite this dilemma.

It does. David's latest trace shows it clearly.

With your changes to curl, it will be quite efficient with IIS 6.0,
and about twice as fast as IE6 for the same large POST requests.

-- Jamie
Received on 2004-11-09