[Pidgin] #11986: Separate HTTP and IM proxy servers no longer work in 2.7.0

[Pidgin]

#11986: Separate HTTP and IM proxy servers no longer work in 2.7.0
------------------------+---------------------------------------------------
 Reporter:  psmith2100  |        Owner:  rekkanoryo  
     Type:  defect      |       Status:  new         
Milestone:              |    Component:  unclassified
  Version:  2.7.0       |   Resolution:              
 Keywords:              |  
------------------------+---------------------------------------------------

Comment(by psmith2100):

 I do appreciate all your responses.  And maybe my frustration is because I
 don't completely understand.  You may have been explaining it well, but I
 am not a developer, I am a network engineer, so I may be missing
 something.

 I think I understand what you are saying now that Yahoo added an HTTP
 component to the account login process and my company's IM proxy only
 supports HTTPS and doesn't support HTTP.

 Corporate networks don't operate that way.  Companies deploy HTTP/HTTPS
 proxy systems for Internet access and to control web content, and this is
 what I define in the Network/Proxy settings.  Companies deploy dedicated
 IM proxy systems, but they aren't going to allow HTTP through the IM proxy
 so people can circumvent the content controls on the dedicated HTTP/HTTPs
 proxy.

 Why can't Pidgin send all HTTP(S) through the HTTP(S) proxy defined in the
 Network settings, and all IM traffic (port 5050 I believe) through the
 account IM proxy?

 What I don't understand is why the account proxy has to handle HTTP(S) and
 IM traffic when there is a perfectly good HTTP(S) proxy defined in Network
 / Proxy settings.  Isn't the account proxy really just to handle the IM
 traffic on port 5050?


 Replying to [comment:7 deryni]:
 > What about the responses you have gotten so far indicate to you that we
 are not looking at this from a "user impact" perspective? (That is a
 serious question, I'd honestly like to know since I don't see it and maybe
 it is something that can be handled better in the future.)
 >
 > The issue you are having was not fixed in 2.6.6, it did not exist in
 2.6.6. Therefore, it was not broken in 2.7.0.
 >
 > The issue that was fixed with the HTTPS workaround option was that
 pidgin was not using the account proxy for HTTPS connections previously
 and thus was failing to work for people who needed to use proxies to make
 that connection.
 >
 > For 2.7.0 an additional phase of the login process was added which
 involves a normal HTTP connection. This connection *does* use the account
 proxy (in your case the IM proxy which does not allow HTTP connections).
 >
 > The problem you are having is that we have no way of letting you tell
 pidgin to make the HTTP connection using the global pidgin proxy as
 opposed to using the account proxy (essentially the opposite of the HTTPS
 issue and workaround).
 >
 > The 2.7.0 changes did not wait because (as has already been mentioned)
 they are required for Yahoo Japan to work at all, anywhere, on any network
 and the calculation (such as it was) was that the number of people using
 Yahoo Japan anywhere likely outnumbered the number of people with
 draconian split IM/HTTP proxies.
 >
 > It is our belief that the official Yahoo client uses the IE proxy
 settings, which allow for a much broader range of configurability than do
 our current proxy settings. I would assume that Trillian does the same
 (though it is of course possible that Trillian just has better proxy
 settings of their own and doesn't need to use the IE settings).
 >
 > The goal with the 2.7.0 change was to look more like the official
 clients in the actual login process not to work with as many disparate
 proxy configurations as they do. We tend to consider the actual network
 traffic being sent to the actual servers as more important than "local"
 details (though I don't know that this tendency had any impact on this
 occasion).
 >
 > Again, nothing was specifically broken (at least as a direct intention),
 no users were specifically targeted for inconveniencing (in fact a group
 of users was the direct target of the fix so that they could work at all).
 >
 > What any development process/outcome that we might or might not actually
 use/have has to say about our user community I have absolutely no idea.
 You are free to make whatever accusations and assumptions about our
 decisions that you like but I would suggest that you actually try to
 listen to what we are saying and understand the issues involved before
 coming to any conclusions.
 >
 > Lastly, we don't write pidgin so that people will use it. We write
 pidgin because we want to. You are free to decide to use some other client
 if those other clients suit your needs better, you are free to tell anyone
 you like that you switched to that client because of those needs, you are
 free to dislike the decisions we make. Threats about your potential switch
 (and the hypothetical mass of followers you will have in your exodus) are
 unwelcome and unconvincing.
 >
 > Consider, if you will, what your reaction would be if our response to
 you had become "We are starting to wonder why we bother supporting
 ungrateful users who complain all the time and accuse of us not even
 trying to care whenever anything happens to break" instead of our repeated
 attempts to explain the issue to you despite your mounting hostility or
 perhaps you'd like to consider how despite the fact that many people like
 you engage us with various levels of anger and hostility we remain
 committed to actually fixing bugs and producing ever more stable, more
 feature-ful, more enjoyable, etc. software that we give away freely to
 anyone who would care to use it and that we continue to attempt to support
 everyone who comes calling. The choice is yours.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/11986#comment:8>
Pidgin <http://pidgin.im>
Pidgin