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
