proxy support for FTP hasn't been implemented

->Judson

The prefs for this are in, is this working yet?

prefs are left over from 4.x. This isn't in yet. All I need to do here is create an http channel w/ the complete FTP url as the http url (http://ftp://blah). FTP proxies are a miss-nomer, they just use an HTTP proxy under the covers.

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

This won't make M13. Need to rework http proxies to make this work.

jud- http proxies work reliably well (except for auth cases which I am fixing right now) but just a note that we'd have to convey from the FTP channel to the HTTP one the original URL. current url semantics wouldn't allow you to just create an HTTP URL and let it work since if you use http://ftp://... we still need to use the proxy on it... Maybe I should add a function on the HTTP channel to specify the proxy host/port. Initially I was thinking if you'd request http://ftpproxyhost:ftpport/ftp://foo then maybe we could do it that way... but in this case we would be sending a / prefixed to ftp://foo in the GET request... We could special case it... but I am not sure if that is the right thing to do. What do you say?

the end result is that we need an HTTP request to go out to an HTTP proxy server that looks like GET ftp://blah HTTP/1 . I was thinking that the HTTP channel itself needs to permit proxy setting. The current HTTP proxy stuff would just use the new api to set the proxy on the channel. If we had this we could do 1 of two things. 1. FTP could kick off an HTTP load and have itself act as the listener for the response, then it would pump the callbacks out to the final consumer. 2. FTP could kick off an HTTP load and hand off the final consumer too. 2 is nice because it takes FTP (the extra layer) out of the loop. But, I wonder if the user will panic if the On*() callbacks it gets back have an HTTP channel in them. Consumers who care about scheme will do wierd things (www.*.com tricks for example might get confused). So maybe 1 is the right move. Either way, I think we need to give nsIHTTPChannel proxy/port attributes. The issue I have w/ #2 is just another reason for some sort of generic channel layer.

I recommend changing the severity to critical. A "normal" severity was fine in October, but this functionality is becoming critical.

*** Bug 25064 has been marked as a duplicate of this bug. ***

waiting for code review.

fix just checked in.

verified: NT 2000021808 Linux 2000021808 Mac 2000021608