On Sun, 1 Mar 2009, Brian J. Murrell wrote:

> I would suggest that if a user could not provide enough information, then a
> round trip is acceptable, but I think the user should be able to provide
> enough information to avoid that. Having to make two round trips for every
> single request is just sub-optimal. It increases latency and litters the
> proxy logs with "false denials".

Indeed. I think this is an issue worth persuing and fixing.

This said, an app that would use more than one request would re-use the
libcurl handle and thus retain the knowledge about the proxy and then not do
round-trips for every subsequent request. It's just of course the fact that if
you use curl it kills the connection all the time so it cannot do this...

> I wonder if we can find 3 people, each with the ability to test one of the
> three. I'm happy to be the "Negotiate" guinea-pig.

I think moving this thread to the curl-library list will increase the chances,
not only that there will be a user like this but that we'll attract interest
from a few other devs.

>> They are covered with a single bit just because we've gotten away with that
>> so far, and we've seen no reason to introduce two separate ones.
>
> But perhaps we are finding the need now for another bit? Or do you still
> think we can, somehow achieve the goal of providing curl with enough
> information to retrieve a URL with only a single trip to the proxy without
> adding a new bit?

Assuming we can do that check for both HTTP@ and KHTTP@ we might still be able
to get away with the single bit. If not, I don't see any reason why shouldn't
add a bit if it makes or allows (lib)curl to behave better.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html