Dear Maintainer,

It is risky to rely on an environment variable to specify a proxy.
Any number of things can wrong, as we know from bug 791452.  E.g., a
user may think incorrectly that a proxy will be used, and have no idea
of any failure.

Having a commandline "--proxy" option would ensure that the users
expectation is known to the tool.  Then if anything is wrong with the
users syntax or something goes wrong with the proxy, lynx can fail
safely and print an error.

--------
[Jack Ryan <noreply@remailer.cpunk.us> writes:]

If user safety is the priority here, but we otherwise want to minimize
our disconnect with the upstream Lynx developer, we might want to
consider instead a --must-proxy flag; connections which are not proxied do
not succeed.  I would propose that this be applied globally; it would
inhibit Gopher, FTP, and others as well as http[s].

Comments welcome.  I can cook this up if it passes the laugh test.

Andy

Andy,

Thanks for the reply.  In principle, I would not be fussy about how
the fail-safe is implemented, so long as there is a means to fail
safely.

But I suggest that whatever the syntax is, it would be useful if it
were consistent with other browsers.  Inventing yet another way of
expressing something adds complexity to the overall gnu environment.
E.g. isn't it a bit irritating that w3m looks for the variable
"HTTP_PROXY", and lynx looks for "http_proxy"?

For the matter at hand, w3m also lacks a fail-safe, so I created bug
792234 at the same time.  Perhaps there could be some coordination.

If lynx aligns with the "links" browser, links has these options:

  -http-proxy <host:port>
  -ftp-proxy <host:port>
  -https-proxy <host:port>
  -socks-proxy <user@host:port>

  as well as this (poorly worded) option:

  -only-proxies <0>/<1>
     "1" causes that Links won't initiate any non-proxy connection.
     It is useful for anonymization with tor or similar networks.

cURL has:

  -U, --proxy-user <user:password>
  -x, --proxy <[protocol://][user:password@]proxyhost[:port]>
  -p, --proxytunnel
  --proxy1.0 <proxyhost[:port]>
  --proxy-ntlm
  --proxy-digest
  --proxy-basic
  --proxy-anyauth
  --proxy-header <header>
  --noproxy <no-proxy-list>

  env vars: http_proxy, HTTPS_PROXY <= it's bizarre that casing is
                                       inconsistent
wget has:

Andy,

Thanks for the reply.  In principle, I would not be fussy about how
the fail-safe is implemented, so long as there is a means to fail
safely.

But I suggest that whatever the syntax is, it would be useful if it
were consistent with other browsers.  Inventing yet another way of
expressing something adds complexity to the overall gnu environment.
E.g. isn't it a bit irritating that w3m looks for the variable
"HTTP_PROXY", and lynx looks for "http_proxy"?

For the matter at hand, w3m also lacks a fail-safe, so I created bug
792234 at the same time.  Perhaps there could be some coordination.

If lynx aligns with the "links" browser, links has these options:

  -http-proxy <host:port>
  -ftp-proxy <host:port>
  -https-proxy <host:port>
  -socks-proxy <user@host:port>

  as well as this (poorly worded) option:

  -only-proxies <0>/<1>
     "1" causes that Links won't initiate any non-proxy connection.
     It is useful for anonymization with tor or similar networks.

cURL has:

  -U, --proxy-user <user:password>
  -x, --proxy <[protocol://][user:password@]proxyhost[:port]>
  -p, --proxytunnel
  --proxy1.0 <proxyhost[:port]>
  --proxy-ntlm
  --proxy-digest
  --proxy-basic
  --proxy-anyauth
  --proxy-header <header>
  --noproxy <no-proxy-list>

  env vars: http_proxy, HTTPS_PROXY <= it's bizarre that casing is
                                       inconsistent
wget has: