87394 - ChatZilla doesn't support HTTP "CONNECT" proxy

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, enhancement)

Description

[Miguelanxo Otero Salgueiro]

chatzilla doesn't have support for http proxy althought it 
is trivial using the HTTP/1.1 method CONNECT.

New irc clients now support http proxy (like xchat version 1.7.x)

Comment 1

[Matthias Versen [:Matti]]

marking new.
see also 71565 and bug 44844

Comment 2

[Bradley Baetz (:bbaetz)]

They do that using irc via ssl, so chatzilla would have to support that first.

See bug 56291, which won't happen for a while.

Comment 3

[Samuel Sieb]

Has anyone tried this recently?  Or is this a dup of the other proxy bugs?
(which were just fixed)

Comment 4

[Samuel Sieb]

I talked to bbaetz and it doesn't look like this will ever happen.

Comment 5

[David Krause]

Remove myself from QA of 33 open Chatzilla bugs and change to default QA
contact, since I have no way to verify these easily.  Still no working Mozilla
on my primary platform and it doesn't look like it will happen anytime soon. :(

Comment 6

[benc]

I can take QA of this if you want.

Are we talking about HTTP proxy or SSL (CONNECT://) proxy? (or both?)

Each type of proxy support should be in a separate bug.

Comment 7

[Tim Martin]

It seems like this is fairly simple.  I managed to insert a handful of lines
into the bc_connect function in connection-xpcom.js which let me connect via an
HTTP proxy, based on this tutorial:
http://www.codeproject.com/internet/httptunneling.asp 

You just need to open a connection to the proxy server, and then, once the input
stream is open, pass it a CONNECT header with the host and port for the irc
server you want to connect to.  (The header I used looked like: "CONNECT
host:port HTTP/1.1\n\n").  After that everything seemed to work fine, with no
other changes to the code. (Although I didn't add any error checking for the
connection attempt).

I don't know the chatzilla code, but hopefully someone could use this info to
fix this bug? :)

Comment 8

[James Ross]

Tim, wow, and thanks for actually messing with the code to try things. :)

One problem I can see is that currently we don't have *any* proxy code... we
just ask Mozilla for a socket transport using protocol "irc", which causes it to
use the "other protocol" proxy options, i.e. the SOCKS 4/5 ones.

Thus we'd need to add some proxy code, and probably have to work out how to tell
the socket transport service what proxy we wanted to use (to let us override the
SOCKS 4/5 stuff). I guess the first iteration could simply be a "Use HTTP proxy"
option, and let Moz do what it wants with SOCKS 4/5 stuff, but that's not ideal.

Thanks for trying anyway, hopefully we'll get around to adding this.

Comment 9

[benc]

There is more to this than hacking the protocol strings in irc.

You need to implement code that optionally wraps any connection in the proxy
specified in a pref.

Ideally, you'd make this compatible w/ PAC as well.

Comment 10

[James Ross]

Why did you change the 'http' in the summary to 'https'? We don't support HTTP
proxies and that was what I thought was wanted here...

We are already 'compatible' with PAC, I believe. I just don't feel like testing
it right now. :)

Comment 11

[benc]

Corrected summary even more...

(In reply to comment #10)
> Why did you change the 'http' in the summary to 'https'? We don't support HTTP
> proxies and that was what I thought was wanted here...

"HTTP proxy" does not mean that HTTP is used for the proxy session, it means the
proxy of classic HTTP requests (like GET http:, POST http:, etc.). Most proxy
servers that proxy HTTP URLs also proxy gopher: and ftp:.

Your idea of a proxy is best described as a URL proxy, because HTTP can be used
for proxy transport of any URL. 

For the proxy of CONNECT requests (often described in browsers as "Secure" or
"SSL proxy" or <very incorrectly in AOL IM> as "HTTPS", that is distinct from
"HTTP proxy".

http://www.packetgram.com/pktg/proxy/protocols.html

> We are already 'compatible' with PAC, I believe. I just don't feel like testing
> it right now. :)

Do you support SOCKS? All PAC is is a javascript function that decides which
proxy method to call.

Comment 12

[James Ross]

(In reply to comment #11)
> "HTTP proxy" does not mean that HTTP is used for the proxy session, it means the
> proxy of classic HTTP requests (like GET http:, POST http:, etc.). Most proxy
> servers that proxy HTTP URLs also proxy gopher: and ftp:.

I never said an IRC "HTTP proxy" used HTTP except as a pseudo-HTTP command to do
the connect... however, it *is* called 'HTTP proxy' by all other clients I know of.

> Your idea of a proxy is best described as a URL proxy, because HTTP can be used
> for proxy transport of any URL. 

Except no-one calls it that.

> For the proxy of CONNECT requests (often described in browsers as "Secure" or
> "SSL proxy" or <very incorrectly in AOL IM> as "HTTPS", that is distinct from
> "HTTP proxy".
> 
> http://www.packetgram.com/pktg/proxy/protocols.html

I've never seen 'HTTPS proxy' mentioned anywhere.

> Do you support SOCKS? All PAC is is a javascript function that decides which
> proxy method to call.

We support SOCKS 5, definately. I don't know if Mozilla works with SOCKS 4 for
this, but if you set a SOCKS 5 proxy in Mozilla or Firefox all IRC connections
use it.

I know what PAC is, thank you. I don't, however, know if Mozilla consults it for
connections on random ports/protocols, or what it does with the results. It's
clearly defined for, say, HTTP, but I've not tried with IRC. IIRC last time I
tried it, no IRC connections worked because the proxy being suggested was only
allowing HTTP connections to be proxied. I've not looked in detail, it's not my
concern, anyway (we ask Moz for a socket from the transport service, it is free
to proxy it however it wants, and that is how SOCKS 5 works).

Comment 13

[Tim Martin]

I don't necessarily know the proper name for what I'm doing, but I can say that
I got it working for me... I couldn't connect to IRC using chatzilla before, but
I can now.  :)

If it will help make clear what I'm talking about, I can paste my ugly, hacked,
code.

Comment 14

[James Ross]

Tim, I think we all know what you're talking about, but just can't agree on the
name of it. :)

Please attach the code, thanks.

Comment 15

[:Gijs (he/him)]

What is the relation between this bug and bug 44844 ?
I have the feeling they are dupes, but that'd depend on what the 'correct'
definition of the proxy would be, and since I know absolutely nothing about the
subject, I'm not going to try and make any decisions about this. I'm just noting
these bugs are *very* similar.

Tim, I think we *would* all like to see your code attached to this bug, even if
it'd just be as a sample. It would help a great deal :-).

Comment 16

[Tim Martin]

Attachment: Modified version of bc_connect,

Oops, finals hit right after I made my last comment, causing me to forget about
this. :) 

Attached is a modified version of bc_connect, located in
chatzilla.jar\content\chatzilla\lib\js\connection-xpcom.js, line 120.
It is hardcoded to use a particular proxy as an http tunnel.

There are just two sections I added; The first sets the http proxy's hostname
and port, and also constructs the header which will ask the proxy to work as a
tunnel.  The second section sends this header to the proxy right after the
connection is made... and that's it, nothing else needs to be modified. 
(Although obviously this does zero error checking, and I only altered the code
path which used necko interfaces.)

Hope this can help. ^_^

Comment 17

[James Ross]

*** Bug 44844 has been marked as a duplicate of this bug. ***

Comment 18

[James Ross]

Attachment: Support proxy type overriding

wheeeee! This patch does a number of fun things.

1. Cleans up the parameters to CBSConnection.connect. It now has all variable
   data passed via the "config" parameter object.
2. Removes entirely the "bind" and "tcp_flag" items, which are unused.
3. Adds support for forcing an HTTP or no proxy for the connection. Values
   other than "http" and "none" will behave as no value (i.e. auto).
4. Adds a pref, proxy.typeOverride, that can set this config option globally
   and per-network. This only applies to the server connection for now - no
   DCC connections will be affected (they will be proxied as they always have,
   via SOCKS, if set).

Comment 19

[James Ross]

Attachment: Updated comment to match code [Checkin: See comment 20]

No major differences, just a comment change. But this is now ready, I think. :)

Comment 20

[James Ross]

Checked in --> FIXED.

Comment 21

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060801 SeaMonkey/1.1a] (nightly) (W98SE) [CZ-0.9.75]

The fix causes
[
Warning: variable uri hides argument
Source File: chrome://chatzilla/content/lib/js/connection-xpcom.js
Line: 187, Column: 12
Source Code:
        var uri = ios.newURI(uri, null, null);
]

Comment 22

[James Ross]

SpiderMonkey really needs to fuck off and die sometimes.

Comment 23

[:Gijs (he/him)]

Attachment: Stop Spidermonkey from complaining [Checkin: Comment 24]

Stopgap measures.

Rubberstamp requested from Silver.

Comment 24

[:Gijs (he/him)]

Comment on attachment 231576 [details] [diff] [review]
Stop Spidermonkey from complaining
[Checkin: Comment 24]

Checked in, fixed.

Comment 25

[Christian :Biesinger (don't email me, ping me on IRC)]

shouldn't you use a https URL for checking whether to use CONNECT?

Comment 26

[James Ross]

I specifically avoided it for two reasons:
  - Some parts of Necko do their own magic for proxied HTTPS, and wasn't going
    to risk is messing things up.
  - We want the HTTP proxy in case that is the only one set.

Comment 27

[Christian :Biesinger (don't email me, ping me on IRC)]

that doesn't really convince me (since if only HTTP is set, why do you need to use a proxy at all? note that this means that HTTPS doesn't use a proxy at all, and if it doesn't need one, why does CZ?)

but anyway... this isn't my module, so your word counts :)

Comment 28

[James Ross]

The user is the one that decides whether we need a proxy. If they decided they want the HTTP proxy they get the HTTP proxy. Note that *many* places are blocking IRC ports (6665-6669) but they wont be blocking HTTPS (443). (Unfortunately, Necko has no for us to let the user enter a specific proxy, so we have to borrow an existing one and HTTP is the best one.)

Comment 29

[Christian :Biesinger (don't email me, ping me on IRC)]

uh, you don't have to borrow anything if you don't want to. nothing stops you from   constructing your own proxy info with nsIProtocolProxyService::newProxyInfo and passing that to the socket transport service. hm, except the fact that that's rather new.

but, for CONNECT, that's irrelevant. you don't need any kind of proxy info for that.

Comment 30

[Serge Gautherie (:sgautherie)]

James / Gijs / Neil:
Could you do the missing checkin to the 1.8 branch ? Thanks.

Comment 31

[Phil Ringnalda (:philor)]

At this point, that branch approval looks rather too stale to still use.