Closed Bug 15594 Opened 25 years ago Closed 25 years ago

FTP needs proxy support

Categories

(Core :: Networking, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: tever, Assigned: jud)

References

Details

(Whiteboard: [PDT+] [02/15/00])

proxy support for FTP hasn't been implemented
Assignee: gagan → valeski
->Judson
Target Milestone: M12
Blocks: 12834
Target Milestone: M12 → M13
Blocks: 20400
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.
Blocks: 22966
Target Milestone: M13 → M14
This won't make M13. Need to rework http proxies to make this work.
Keywords: beta1
Whiteboard: [PDT+]
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.
Depends on: 27024
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] [02/15/00]
*** Bug 25064 has been marked as a duplicate of this bug. ***
waiting for code review.
fix just checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
verified:
NT 2000021808
Linux 2000021808
Mac 2000021608
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.