Closed
Bug 15594
Opened 25 years ago
Closed 25 years ago
FTP needs proxy support
Categories
(Core :: Networking, defect, P3)
Core
Networking
Tracking
()
VERIFIED
FIXED
M14
People
(Reporter: tever, Assigned: jud)
References
Details
(Whiteboard: [PDT+] [02/15/00])
proxy support for FTP hasn't been implemented
Updated•25 years ago
|
Assignee: gagan → valeski
Comment 1•25 years ago
|
||
->Judson
Assignee | ||
Updated•25 years ago
|
Target Milestone: M12
Assignee | ||
Updated•25 years ago
|
Target Milestone: M12 → M13
Comment 2•25 years ago
|
||
The prefs for this are in, is this working yet?
Assignee | ||
Comment 3•25 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M13 → M14
Comment 5•25 years ago
|
||
This won't make M13. Need to rework http proxies to make this work.
Updated•25 years ago
|
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?
Assignee | ||
Comment 7•25 years ago
|
||
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.
Comment 8•25 years ago
|
||
I recommend changing the severity to critical. A "normal" severity was fine in October, but this functionality is becoming critical.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] [02/15/00]
Assignee | ||
Comment 10•25 years ago
|
||
waiting for code review.
Assignee | ||
Comment 11•25 years ago
|
||
fix just checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•25 years ago
|
||
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.
Description
•