[JDEV] Which to pick, "HTTP proxy passthrough" or JEP-0025?
Hiroaki Nakamura
hnakamur at v003.vaio.ne.jp
Sat Jul 27 08:37:31 CDT 2002
Hi Matthias!
> (Sorry for not being famillar with Japanese names. What part of the name
> should I use for English internet greetings?)
Hiroaki is my given name and Nakamura is my family name, So "Hi Hiroaki!"
is perfect. In Japanese, we write a family name followed by a given name.
In English, most people write a given name followed by a family name, but
some people write like "NAKAMURA Hiroaki" or "Nakamura, Hiroaki" .
Matthias Wimmer wrote:
> Hiroaki Nakamura wrote:
>
> >What about performance? I think HTTP proxy passthrough may be faster.
> >
> Sure ... with proxy passthrough the server can push you new XML packets
> when they are available. With JEP-0025 it has to wait for the client
> polling the information. But it's a real problem that this method is not
> supported by all proxies (because it violates the RFCs not to send a
> Content-Length header with a POST or PUT request). E.g. it's not
> possible to use this with out-of-the-box squish.
If you build the content as a string before sending, you can calculate
the content length and you can send a Content-Length header?
As for sending file, you can also precalculate the content length by
getting the file length.
I read JEP-0025 and understand the real problem is that proxies do
not allow HTTP Keep-alives. Am I correct?
> >As for security problems, JEP-0025 with https would be no problem?
> >1.client -"connect jabber.org:443"-> HTTP proxy
> >2.proxy --> jabber.org:443
> >3.jabber.org:443 --> jabber.org:5222 or jabber.org:5223
> >
> Yes, this would be no problem. But I would layer it up the other way
> round: Make your polls with http and use a jabber-ssl connection over
> it. You don't have to reestablish the SSL context with every poll then.
Well, what you are saying is like below?
1.client --"connect jabber.org:80"_via_http--> HTTP proxy
2.proxy --via_http--> jabber.org:80
3.jabber.org:80 --via_https--> jabber.org:5223
And in 1 and 2, contents are encrypted, and 3 is just forwarding.
Is this what you are saying?
> With the proxy-connect method you get a plain connection to the server
> and don't need to modify the jabberd. The only problem with it is that
> most proxies only accept connections to port 443 (this can be
> configured, but in most of the cases you don't have control over the proxy).
> What I'm doing at my Jabber server (http://amessage.info/) is to listen
> on port 443 for incoming jabber connections (I'm just forwarding
> connections to port 443 to port 5222). "CONNECT amessage.info:443"
> should work with nearly any proxy installation that doesn't block "https".
I now understand the most proxies only allows the port 443 as https.
In most cases, the port 443 is already used by a web server.
If it is Apache, then can I use mod_proxy to forward connections from
port 443?
As for the destination port, I think the forwarding is like
port 80 -> port 5222
port 443 -> port 5223
Am I wrong? Well, I am not sure about that.
(snip)
> The security problem of JEP-0025 could be fixed. I have written a
> working extension of JEP-0025 with a protocol that was discussed in this
> list some weeks ago. But I have never published this because I am not
> sure if it is right to do that much work to bypass firewalls without
> being allowed by the admins of these proxies.
Well, in the ideal world, each protocol is assigned to a port number.
But actually, there are already many protocols which does http tunneling.
So why not one more? :) Seriously I hope you publish your work.
Please publish it.
> >PS. At Exodus sourceforge site, I have submitted two patches
> >http://sourceforge.net/tracker/index.php?func=detail&aid=587361&group_id=2049&atid=202049
> >http://sourceforge.net/tracker/index.php?func=detail&aid=587373&group_id=2049&atid=202049
> >and one request.
> >http://sourceforge.net/forum/forum.php?thread_id=710505&forum_id=5896
> >
> And what are they for?
I will write in another mail.
--
)Hiroaki NAKAMURA) hnakamur at v003.vaio.ne.jp
More information about the JDev
mailing list