[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 datallah):

 Replying to [comment:39 psmith2100]:
 > It looks to me that the 2.7.0 and later are trying to send non HTTP
 traffic through the HTTP proxy and that is why the content filters are
 denying the traffic and asking for authentication.
 [[BR]]

 It isn't non-HTTP traffic though; it just appears to be an address your
 proxy doesn't like.

 If you visit http://vcs1.msg.yahoo.com/capacity with your browser, does
 that work?

 [[BR]]
 > Replying to [comment:38 psmith2100]:
 > > 2.7.2 did not work but I think I see the problem.  I have attached
 three files.  I have attached debug2.7.2.txt and 2.7.2.cap and 2.6.6.cap.
 The "cap" files are sniffer traces.  Download Wireshark www.wireshark.org
 to view the sniffer files.
 [[BR]]

 Excellent, this is what we were wishing we had and it clears up some
 uncertainties.

 [[BR]]
 > > 2.7.2 is sending traffic through our HTTP proxy that is not permitted
 by content filters and that is why we see the authentication required
 message in the debug and in the 2.7.2.cap file.  2.7.2 contacts the HTTP
 proxy first instead of contacting the IM account proxy first.
 [[BR]]

 It doesn't appear to actually be the content that is the problem as much
 as the address (we haven't sent any content apart from a valid HTTP
 request when we get the error).  The server also sends a valid HTTP
 response that is text/plain.

 [[BR]]
 > > However, you can see in the 2.6.6.cap file that 2.6.6 contacts the IM
 account proxy first and a significant amount of traffic goes to the IM
 proxy before the HTTP proxy is ever used.  The HTTP proxy is first
 contacted at line 17, and line 20 is the first HTTPS traffic ever sent and
 it goes to login.yahoo.com:443.
 [[BR]]

 The order of operation isn't likely to be important.  I suspect that the
 problem is really that your proxy is blocking the address that we perform
 the initial query against.

 I believe rekkanoryo is planning to try to tweak the fallback
 functionality to work around this issue, but the problem isn't broken
 proxy support as much as an overly restrictive proxy.

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