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