George Rizkalla <grizkalla_at_rim.com> wrote:

> On 7/25/12 11:44 AM, Fabian Keil wrote:
> >
> >How do you intend to deal with HTTP proxies?
> >
> >If an HTTP proxy is used, the socket isn't directly connected to the
> >server and may be used for requests to different servers. curl already
> >does that.
> >
> >It's also possible that the server supports pipelining while the
> >proxy does not (or only poorly).
>
> The proxied case is a bit trickier to get right. Nottingham suggests some
> methods for faulty proxy detection:
> http://tools.ietf.org/html/draft-nottingham-http-pipeline-01#section-5 .

Which could be considered "phoning home", even if the intentions are good.

> Joe and I had some discussion about where we believe the best place for
> implementing this sort of faulty proxy detection is. Our inclination was
> to keep this out of the protocol stack itself (although we're certainly
> open to suggestions!).

I agree that this doesn't really belong in libcurl. I'd be fine either
way, though, as long as it's not done without being explicitly requested.

> If a client is going through a faulty proxy, there are two cases to be
> dealt with:
>
> (1) The client is going through a transparent faulty proxy (i.e. We don't
> have an identifiable host)
> (2) The client is going through a non-transparent faulty proxy (i.e. We
> have an identifiable host)
>
> For (1), the application might simply disable pipelining entirely.
>
> For (2), it might make most sense for the app to pass in a proxy blacklist
> just as it would a standard host blacklist.

Or apply the standard host blacklist to the proxy as well (unless that's
already what you are referring to). Do you see any advantages in having two
separate blacklists?

> Does that seem reasonable?

Seems reasonable to me.

Fabian

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html