Bug 25494
| Summary: | fetch uses environment variable FTP_PROXY, ftp/lynx use ftp_proxy | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | mike <mike> | ||||
| Component: | bin | Assignee: | Dag-Erling Smørgrav <des> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | 4.2-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
mike
2001-03-02 16:40:01 UTC
mike@pelley.com writes: > Change fetch to support lowercase ftp_proxy/http_proxy as well, > and change man page to only mention the lowercase versions. Is this really the correct fix? Does lynx really apply the exact same semantics to ftp_proxy / http_proxy as libfetch does do FTP_PROXY / HTTP_PROXY? (me, I'm tempted to say the correct fix is "don't use lynx, use w3m") DES -- Dag-Erling Smorgrav - des@ofug.org > Is this really the correct fix? Does lynx really apply the exact same > semantics to ftp_proxy / http_proxy as libfetch does do FTP_PROXY / > HTTP_PROXY? ftp is in the base system and it also uses ftp_proxy/http_proxy. The use of these environment variables is very similar between the two (and lynx) as far as I can tell - but perhaps I'm missing something? I think consistency is important - it seems incovenient to have two variables that do the same thing. > (me, I'm tempted to say the correct fix is "don't use lynx, use w3m") This doesn't quite seem relevant, but ftp should be enough to justify it regardless. Mike. "Mike Pelley" <mike@pelley.com> writes: > ftp is in the base system and it also uses ftp_proxy/http_proxy. Only when talking HTTP, and there is already consensus for removing the (horribly useless and broken) HTTP code from ftp(1). It just hasn't been done yet. DES -- Dag-Erling Smorgrav - des@ofug.org > > ftp is in the base system and it also uses ftp_proxy/http_proxy. > > Only when talking HTTP, and there is already consensus for removing > the (horribly useless and broken) HTTP code from ftp(1). It just > hasn't been done yet. I'm not familiar with those discussions - it does seem to provide me with the functionality I need behind the proxies at work but obviously there are other problems (although horribly useless and broken is not true for everyone). However, an attempt at consistency should be made. It appears that wget, lynx, links and ftp use http_proxy, and w3m and libfetch use HTTP_PROXY. Supporting both in libfetch seems like a reasonable patch. Mike. "Mike Pelley" <mike@pelley.com> writes: > I'm not familiar with those discussions - it does seem to provide me with > the functionality I need behind the proxies at work but obviously there are > other problems (although horribly useless and broken is not true for > everyone). Trust me, it's horribly useless and broken. It's barely more functional than an HTTP/0.9 client - the only part of HTTP/1.0 it actually implements correctly is parsing the Content-Length header. It can't talk to virtual hosts (except through a proxy), and it can't fetch the output of a CGI script (no chunk decoder), to name only two major shortcomings. DES -- Dag-Erling Smorgrav - des@ofug.org > Trust me, it's horribly useless and broken. It's barely more
> functional than an HTTP/0.9 client - the only part of HTTP/1.0 it
> actually implements correctly is parsing the Content-Length header. It
> can't talk to virtual hosts (except through a proxy), and it can't
> fetch the output of a CGI script (no chunk decoder), to name only two
> major shortcomings.
That's not horribly useless and broken - that's limited. Oddly enough, none
of these problems have caused me any trouble retrieving via HTTP.
This is off-topic however. I think the patch should be applied to improve
consistency, but to each his own.
Mike.
"Mike Pelley" <mike@pelley.com> writes: > That's not horribly useless and broken - that's limited. Oddly enough, none > of these problems have caused me any trouble retrieving via HTTP. You've probably never used it without a proxy. > This is off-topic however. I think the patch should be applied to improve > consistency, but to each his own. A similar change will be committed within the hour. DES -- Dag-Erling Smorgrav - des@ofug.org > You've probably never used it without a proxy. I often use it without a proxy - it's on my laptop. > A similar change will be committed within the hour. Cool! Mike. Dag-Erling Smorgrav <des@ofug.org> wrote: > > Trust me, it's horribly useless and broken. It's barely more > functional than an HTTP/0.9 client - the only part of HTTP/1.0 it > actually implements correctly is parsing the Content-Length header. It > can't talk to virtual hosts (except through a proxy), and it can't > fetch the output of a CGI script (no chunk decoder), to name only two > major shortcomings. It'll never see HTTP/1.1 chunked content encoding because it's an HTTP/1.0 client. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTHEASTERLY 5 INCREASING 7 OR GALE 8. RAIN LATER. GOOD BECOMING MODERATE. Tony Finch <dot@dotat.at> writes: > It'll never see HTTP/1.1 chunked content encoding because it's an > HTTP/1.0 client. If only it were so well... I'd love this to be true, I'd be able to rip the chunk decoder out of libfetch so it wouln't need the (non-portable) funopen() interface. Unfortunately, the words "MUST NOT" do not seem to mean anything to server authors. DES -- Dag-Erling Smorgrav - des@ofug.org Responsible Changed From-To: freebsd-bugs->des libfetch is mine. State Changed
From-To: open->closed
Support for {ftp,http}_proxy has been added in -CURRENT and -STABLE.
|
