Am 11. Jan 2005, um 12:54:57 schrieb Michael Vogt:
> But I keep wondering why the "putenv("no_proxy")" call is there in the
> first place?
>
> I tested the behaviour of this attached patch with squid and it works
> fine.
Its simply too late to make this call.
The problem is that direct ftp is handled via the ftp backend,
however proxied ftp, together with proxied_http and direct http,
is handled via the http method.
For that, it sets http_proxy to what ftp_proxy is (so that the
http backend uses the proper proxy, after all the operation will be
a ftp-over-http-operation), and then forced no_proxy to be empty,
so that the http method WILL use the proxy in any case.
Unless (i havent personally checked yet) the http backend recognizes
it is doing a ftp:// URL where no_proxy matches, and then executes
a new ftp method (for http can not itself handle unproxied ftp transfers),
this helps in some configurations, but not in all.
As pointed out in the original bug report, the decision on wheter
no_proxy aplies needs to be made earlier in the process, so that
if ftp_proxy is set, but ruled out by no_proxy, the ftp backend
will do the work by itself, and not hand it over to http in the
first place.
Mario
--
Mario Lorenz Internet: <[EMAIL PROTECTED]>
Ham Radio: [EMAIL PROTECTED]
"Your mouse has moved. Windows NT must be restarted
for the change to take effect. Reboot now ? [ OK ]"
