Thanks, Daniel. I'm not aware of an easy way for the caller who doesn't have
context of these other requests occurring to separate out the headers from
the different responses, so I appreciate the consideration of an option to
make this easier for apps to get at just the ones from the final response.

It would be great too if the docs could be updated to reflect that the
current option returns headers from the multiple responses which occur
during auth negotiation and not just the final response. I believe these
changes would make it easier to use the library. Thanks.

-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se
[mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Saturday, June 06, 2009 8:01 AM
To: libcurl development
Subject: Re: Design Change Proposal: Transparent Authentication Negotiation

On Fri, 5 Jun 2009, Aaron Oneal wrote:

> When a caller uses a networking API like libcurl to make an HTTP request,
> the expectation is for a single response and for the response to correlate

> with the request.

I would say so as well. But I would specify and say that a user expects a
single response-body. And that is what users get.

For users that also want the response-headers, it is a lot harder for us to
know exactly what headers these users might want or not.

> Unfortunately, libcurl today actually passes information back to the
caller
> from auth negotiation. Register CURLOPT_HEADERFUNCTION and you'll get all
> the headers from the first response and the second one. This can cause
> problems when from a caller perspective it made one request, is expecting
to
> get back one response, and instead gets two.

If it causes problems we haven't documented the behavior properly or the app

author hasn't read that docs properly.

> A problem example is when trying to determine the status code of the
> response. Most client code would assume headers from only the final
response
> to be returned and would not be expecting to receive multiple status code
> lines.

Most? Really? libcurl has worked like this since always so I would expect
that
most clients that use libcurl already have adapted!

> If a client actually needed this information, it could certainly turn off
> authentication, make separate requests, and handle the 401's itself.

That's a rather naive assumption imho, because of at least two points:

A) treating 401/407 yourself would force you to implement all the auth code
    yourself, which isn't trivial

B) there might be other headers than the Authentication: that a client is
    interested in

> I propose that libcurl should insulate the client from auth exchange and
> that such headers should not be passed back to the caller. This convention

> is consistent with other libraries that support HTTP such as WinInet,
> WinHTTP, and System.Net.HttpWebRequest.

I've never used those libraries and frankly, I don't care for consistency
with
them.

I do care for features that make libcurl useful and good, and easy to use
and
yes I can see how this could be useful to simplify the applications' efforts

to only get the response-headers after the authenticate negotiation.

> I understand the current behavior has been around from day one, however, I

> do not believe that it is a desirable one. Please consider changing this
> design to be more consistent with caller expectations and conventions from

> other libraries. Thank you.

I cannot see how we would _change_ this design, but I would be willing to
introduce an option or a way to make libcurl behave like this.

Personally I don't feel this is a very important feature, but I'll certainly

help out if anyone decides to have a go at working on it.

-- 
  / daniel.haxx.se