Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#3817 closed Enhancement (invalid)

Use the OS' proxy support

Reported by: charles Owned by: charles
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.12
Severity: Normal Keywords:
Cc: patrickegleason@…, bulljit@…

Description

In ticket #3688 ("remove proxy support") I described how I thought Transmission's proxy support as half-assed, and didn't think many people used it. The conclusion was to remove the feature to see if anyone noticed, as a way to measuring how important the feature was to users, and whether peer-based support should be added.

Well, lots and lots of users noticed. To my surprise, few (if any?) people cared about peer proxy support, but tracker proxy support is a Big Deal to some people. Many users located in Europe and Asia cited privacy concerns.

Another related issue dovetails this one -- GNOME and OS X both have systemwide proxy support. Some insightful users suggested that instead of using its own proxy settings, Transmission could "piggyback" on the system's proxy settings.

This sounds like a pretty good idea to me, which kills two birds with one stone. It would restore tracker proxy support, but without reinventing the wheel -- the support would come from the system rather than from Transmission.

transmission-gtk: should use gnome-control-center's "Network Proxy Preferences" app. (The gconf2 keys are documented at http://ant.apache.org/manual/proxy.html)

transmission-mac: should use OS X's preferences as Safari does. In Safari, there's a "Proxy" button that opens the OS X Proxy Settings.

transmission-daemon: document libcurl's http_proxy environment variable.

transmission-qt: ?

Change History (37)

comment:1 Changed 7 years ago by charles

  • Owner set to charles
  • Status changed from new to assigned
  • Summary changed from Honor the OS' proxy settings to Use the OS' proxy support

comment:2 Changed 7 years ago by charles

Added for libtransmission, transmission-gtk in r11512

comment:3 Changed 7 years ago by charles

  • Version changed from 2.13 to 2.12

comment:5 Changed 7 years ago by garrych

I'm for the old solution. I have my Safari with direct access to the web, while T was announcing through socks proxy of Tor network. So I prefer for every client to have his own proxy setting.

comment:9 follow-up: Changed 7 years ago by gunzip

i just installed transmission-daemon 2.13+ (11512) but didn't see anything in settings.json like

enable-system-proxy

or will the daemon automatically use it if the environmental variable http_proxy is not a null value?

EDIT:

i googled for some free proxies and then tried this:

export http_proxy="http://174.142.24.204:3128"
started the transmission-daemon

but when i ran "transmission-remote -l" error results:

Unexpected response: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access http://localhost:9091/transmission/rpc
on this server.</p>
</body></html>
Keep-Alive

OS Linux Debain

Last edited 7 years ago by gunzip (previous) (diff)

comment:11 in reply to: ↑ 9 ; follow-up: Changed 7 years ago by charles

Replying to gunzip:

will the daemon automatically use it if the environmental variable http_proxy is not a null value?

It should; yes. The next step for -daemon and -remote is to document the http_proxy environment variable in the manpage and probably the --help message.

EDIT:

i googled for some free proxies and then tried this:

export http_proxy="http://174.142.24.204:3128"
started the transmission-daemon

but when i ran "transmission-remote -l" error results:

Unexpected response: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access http://localhost:9091/transmission/rpc
on this server.</p>
</body></html>
Keep-Alive

My guess is that what's happening is that -remote is picking up the same proxy setting as -daemon. Do you have an IP whitelist enabled? If so, is your proxy on it? If not, you might want to unset the http_proxy variable in the shell that's running -remote.

comment:12 Changed 7 years ago by livings124

  • Milestone changed from 2.20 to None Set

comment:13 in reply to: ↑ 11 Changed 7 years ago by gunzip

Replying to charles:

My guess is that what's happening is that -remote is picking up the same proxy setting as -daemon. Do you have an IP whitelist enabled? If so, is your proxy on it? If not, you might want to unset the http_proxy variable in the shell that's running -remote.

Yes i have rpc-whitelist enabled and had thought about adding the proxy to it, but didn't like idea since i'd also have to open port 9091 to the outside world. i prefer to keep all the rpc stuff restricted to my LAN.

But your second idea of running tr-remote from a shell with http_proxy unset did the trick -- i once again had access thru localhost:9091

i tried a torrent from a private tracker but did get an announce error "tracker gave HTTP Response Code 502 (Bad Gateway)", probably because the free proxy i googled at random was meant for web browsing only, otherwise i believe it would have worked fine.

comment:14 Changed 7 years ago by charles

Qt support added in r11514

comment:15 Changed 7 years ago by charles

added http_proxy documentation to transmission-daemon and transmission-remote manpages to r11512

Last edited 7 years ago by charles (previous) (diff)

comment:16 Changed 7 years ago by charles

This is completed now except for the Mac client

comment:17 Changed 7 years ago by johndoe32102002

Thank you for adding back proxy support. Any proxy support is welcome.

One word of caution: Some users may not want to proxy all OS data (e.g. web-browser), just torrent data.

comment:18 Changed 7 years ago by pong

Oh man I don't know what to say, the situation looks very sad from here.

It is bad that the feature was removed and I believe that the proposed remedy actually makes the situation a bit worse. Sadly it appears that more than half of the "solution" has already been completed. Hopefully, what is needed is not too far from that.

The proposed solution is to use the OS's default proxy settings to garner automatically determined proxy settings for Transmission.

The problem with this solution relates to the specialization of proxies. It also affects general internet usage.

Safari uses the OS's default proxy settings, primarily those for HTTP and HTTPS data exchanges. This poses a problem for implementing the use of an automatic, unalterable proxy in Transmission. As the main reason one uses a proxy is to circumvent data exchange obstruction and since ordinary web browsing is not often obstructed, adding a proxy in between ordinary web browsing is an unnecessary and easily averted inefficiency. The solution to this is to use Firefox however this is not exactly a desirable solution.

Specialization of proxies refers to the fact that nearly any good web proxy (HTTP, HTTPS) is unlikely to support tracker proxying. This is probably through simple packet analysis methods which obstruct those going to certain IP's (trackers). If web browsing and torrenting were forced to use the same proxy, then the inefficiency introduced is again on the web browsing aspect of internet usage since one would have to choose a proxy efficient at tracking however not very hasty with web browsing, this time more pronounced for those who are forced to use a proxy for certain web browsing. Again the solution is to use Firefox.

In conclusion, it is best to let the user determine proxy settings for web browsing clients and torrenting clients separately as otherwise there are unnecessary inefficiencies introduced.

comment:20 Changed 7 years ago by charles

r11515: added manpage documentation for transmission-remote and transmission-daemon.

r11520: added manpage documentation for transmission-cli and transmission-gtk.

comment:21 Changed 7 years ago by norenore

Can we please not use OS or global proxy settings? There are many of us that use proxies purely for tracker communication as that is all is necessary. Furthermore, making the user change configurations in two separate applications is incredibly unintuitive and is only useful based on the ill-conceived assumption that people who use proxies use them for all applications system-wide (and, additionally, that they use the same proxy for all of them).

The previous method for proxies worked just fine. Let's just revert that and save everyone time and effort.

comment:29 Changed 6 years ago by jordan

I thought I had addressed this already, but since ijuxda has asked again in the forums, maybe I wasn't as clear as I thought I was. For posterity's sake of the people reading this ticket: prior to 2.12 the development team had almost zero feedback on proxies. My feeling was that the code wasn't very good and that few people used it. I decided to remove the feature, intentionally without announcement, to see how many people noticed, and to use that feedback to determine how important proxies are.

In retrospect, this should have involved more steps. An IRC user (jlouis) suggested I try Keith Packard's "fail-safe method for the removal of cruft from an old code base" outlined at http://lwn.net/Articles/354408/ ... solid advice IMO.

Last edited 6 years ago by jordan (previous) (diff)

comment:30 Changed 6 years ago by ijuxda

Thank you for clarifying why there was no mention of the removal in the release notes. I would also gladly welcome adherence to Keith Packard's method in the future, but note that it does not provide a fail-safe method to determine which code is "cruft" in the first place, or how much complaining is necessary to reinstate a removed feature. Or have I misunderstood the article as relating to #3688 and this ticket?

On a more technical note, here is a summary of the problems that I know of with respect to the approach taken by the changes in this ticket:

  • For the gui clients: there is no way to set a network proxy for only transmission, or only for certain running instances of transmission. Usage examples: (1) A user wishes to proxy tracker requests for privacy reasons, but does not wish to proxy other network communication for performance reasons. (2) A developer wishes to proxy tracker requests from a development version for debugging purposes, but does not wish to use a proxy for other running transmission instances.
  • For gtk: Not everyone uses gnome, therefore not everyone has "gnome-network-properties", gconf-editor, gconf2, their dependecies, and so on, installed.
  • There is no way to extend the proxy capabilities beyond what the underlying library call or OS supports already. For example it cannot be known whether UDP communication would be supported, or whether peer-proxing would be possible.
  • There is no way to set different proxies for different communication types, e.g. different proxy settings for torrent file downloads and tracker communication.
  • There is no way to assure feature uniformity across the different transmission front-ends: each would have different proxy capabilities based on what the underlying library/OS provides, and this could never be fixed by more work on just the transmission codebase.

comment:31 Changed 6 years ago by jordan

let's see how it works in practice in 2.20

comment:33 in reply to: ↑ 32 ; follow-up: Changed 6 years ago by ijuxda

Replying to jordan:

let's see how it works in practice in 2.20

Will user feedback be considered when evaluating how well the approach works in practice? If not, how else could someone determine whether the design and implementation choices were adequate?

comment:39 Changed 6 years ago by rosc

My two bars of pressed latinum:

1) For every one person who bothers to post or otherwise respond, assume that that one person is expressing similar thoughts for at least 10 people who didn't bother to post or otherwise respond (some producers assume 100 non-respondents, some assume 1000, depending on market-size.) "For every person who complains, there are perhaps 10 others who have simply gone away and taken their business elsewhere without you ever realising that they were unhappy with your product or service." http://www.safeworkers.co.uk/DealingWithDifficultCustomers.html

2) Not documenting the removal of the proxy change is provocative. Programming and system administration are generally thankless jobs, and you won't hear from users unless something is broke - so assume "no news is good news" when you're not hearing much from users.

3) Please bring back the proxy config tab.

4) Please enhance the proxy options to have "use proxy for tracker" and "use proxy for all p2p traffic" as separate options.

5) Thanks for all your work on Transmission :)

6) I use gtk but not gnome, so I don't know how this gconf2 thing is gonna work - I don't have it and don't want gnome, I use the minimal amount of gnome libs to get gtk working.

comment:41 Changed 6 years ago by rosc

Additional feature request for proxies: Have a list of trackers that don NOT use the system proxy, since some private trackers reject proxies, and there's currently no apparent way around this, except perhaps running multiple instances of transmission, one with the default proxy and one without to access the no-proxy trackers.

comment:43 Changed 6 years ago by jordan

jordan * r11805 gtk/main.c:

#3817 "use the OS' proxy support" -- fix memory leaks in the GTK+ implementation.

r11512 introduced a handful of memory leaks by not freeing the GConfValue objects after use.

comment:44 in reply to: ↑ 33 Changed 6 years ago by patg

Replying to ijuxda:

Replying to jordan:

let's see how it works in practice in 2.20

Will user feedback be considered when evaluating how well the approach works in practice? If not, how else could someone determine whether the design and implementation choices were adequate?

I think this is important-if this feature was first axed for lack of user feedback, hopefully enough user feedback can bring it back. Is a reevaluation of this slated for a certain milestone or time table? And of course I would like to add my voice to those clamoring for the old method for all the same reasons it doesn't make sense to use global proxy settings.

Another suggestion I have-the user should have some control over how Transmission interacts with proxies-for instance; if a connection to/through a proxy fails, Transmission at should give the user options of what to do. Send the announce directly? Send nothing? (Similar to prefer/ignore encrypted/unencrypted peers) At the very least there could be a status light like for an open port that indicates the health of the tracker announces.

Silver lining of this whole mess-it has brought some lurkers like me into the fold of the conversation. (great point above about assume 10 users for each represented here.)

Thanks again for all your hard work on Transmission

comment:45 Changed 6 years ago by patg

  • Cc patrickegleason@… added

comment:46 Changed 6 years ago by cypherpunks

I'd like to add some more important reasons why users want differentiated proxy settings for torrent tracking: proxies break and may not be trustworthy. Using a junk ssh shell, vps, tor, or free web proxy for just tracker traffic is one thing, but sending all of your *OS TRAFFIC* though this same proxy can be outright insane. If you don't keep this proxy up and online, you will miss critical OS security updates and certain network sensitive components of your computer will just break (like random dashboard widgets). Your proxy may also malfunction on certain types of HTTP requests, causing OS updates and other critical system network activity to fail silently on you. Worse still, passwords and other credentials can leak through an untrusted (but tracker-acceptable) proxy for your mail client, twitter client, facebook, etc etc etc.

Furthermore, many open proxies do not have the bandwidth for all torrent/OS traffic, but work just fine for accessing blocked or censored tracker hostnames. Tor for example is great for tracker traffic, but is too slow for all torrent traffic (and the tor web pages beg you not to run data torrent traffic over it, too).

I'd also like to echo what the posters who want proxy support above have said. Especially since most of your users probably won't be going through the hassle of making a trac/forum account to tell you they need proxy support to access blocked or censored trackers: they will just switch torrent clients.

comment:47 Changed 6 years ago by steubens

signed up just to comment on the removal of proxy support, when i saw the tab for it disappear i assumed it started using OS settings and just changed it there, kind of got a little burned on some stuff because it didn't. and there was nothing really all that discoverable about its removal.

is it enough to say here that i'd like the proxy removal change reverted or the old proxy support re-added? or should another ticket just for that be opened.

comment:48 Changed 6 years ago by NotUsed

Have proxies be reinstated in 2.30b3?

I'm still with 2.11 due to issues. I'm unable to set the entire OS to use proxies. Therefore I can not use a newer version of Transmission unless I want my IP available to the world.

comment:49 Changed 6 years ago by ImG

  • Milestone changed from None Set to 2.32

comment:50 Changed 6 years ago by livings124

  • Milestone changed from 2.32 to None Set

Do not set milestones.

comment:51 Changed 6 years ago by jordan

There's a lot of unhappy people in this ticket who don't like its proposal. A question to the Linux users who get mailed when this ticket updates -- are any of you actually using the desktop proxy support? Is it a waste of time?

comment:52 Changed 6 years ago by rosc

Pretty much useless the way it is now, since I don't use gnome and don't want a "whole system" proxy as transmission now expects. I could probably set custom env vars in a launcher script, but CBA. The old method was preferable.

comment:53 Changed 6 years ago by patg

It is most certainly a waste of time. Basically I would be dedicating a computer to just transmission when using desktop proxy support. Low CPU usage and small memory footprint dont mean anything if everything has to go over the proxy. I just ended up going back to using the versions that had this feature. Guess 2.11 for Mac and whatever version ships with Debian Squeeze is good a version as any to end on.

comment:54 Changed 6 years ago by steubens

not to endorse even this proxy support being removed as well, but yes, kind of useless; for people who need proxies to even reach the internet it might still be useful, but for all other uses separate settings inside transmission are preferable.

comment:55 Changed 6 years ago by bulljit

  • Cc bulljit@… added

comment:56 Changed 6 years ago by jordan

It would be fair to call OS proxy support a failed experiment. The people who don't use proxies don't care how it's implemented, and it appears that the people who want proxies don't want it integrated with the desktop.

For example, the OS X client never added OS X proxy support, but the complaints have been pretty even across both the OS X and GTK+ clients.

In addition, despite asking both here and in the forums, not even one user has spoken up in favor for OS proxy support. The kindest response for it so far has been "kind of useless" ...

Last edited 6 years ago by jordan (previous) (diff)

comment:57 Changed 6 years ago by jordan

  • Resolution set to invalid
  • Status changed from assigned to closed

r12461: remove OS proxy support.

comment:58 Changed 6 years ago by johndoe32102002

I have had to go to older versions to use proxy support. Who in the world REMOVES useful features from their products?

Note: See TracTickets for help on using tickets.