I have been following the development of HTTP Binding in Wildfire and other jabber servers with great interest the last couple of months. I want to create a site embedded AJAX based jabber chat client for a large community based website. To me, HTTP Binding seems like a more efficient and elegant method of communicating with the jabber server then HTTP Polling. Instead of hammering my jabber server with 1000’'s of simultaneous pings looking for new messages or updates, I could create just create a couple hundred long lived connections.
I have read Alex’‘s blog post. Alex’'s raves on how the newly embedded Jetty 6.0 server will efficiently handle these large number of client connections. All of this sounds wonderful and exciting.
The only thing stopping us from experiencing this HTTP Binding goodness is the “The Same Origin Policy” of Mozilla and Internet Explorer. It states that any browser request MUST be to the same host, port, and protocol it was called from. Read Here
You cannot serve the HTML, AJAX, PHP, JavaScript or whatever files from the same origin as the Jabber server.
THIS REALLY BLOWS!!!
The main way discussed to get around this restriction is to proxy all of the jabber connections THROUGH my web Apache web server. The new Jetty 6.0 server may be able to handle all of these open connections but Apache cannot! The very beauty and elegance of HTTP Binding is destroyed by this hack!
I really want to use HTTP Binding but I haven’'t come up with a way to get around this restriction.
These are some of the options I’'ve been mulling over:
Somehow break the “The Same Origin Policy” described above.
Ditch Apache and use Jetty 6.0 as my main web server. Can the embedded Jetty server be used as a web server? If it can, can it efficiently handle and proxy these connections in the same way Wild Fire does?
Has anyone come up with an efficient way to make this work?
You cannot serve the HTML, AJAX, PHP, JavaScript or whatever files from the same origin as the Jabber server.
Can you explain why this is not possible? For me this works great, I use a reverse proxy with a rewrite map to connect to various backend servers depending on the request.
“You can only serve the HTML, AJAX, PHP, JavaScript or whatever files from the same origin as the Jabber server.”
If you read my entire post you’‘d see what’'s what I meant. Proxying all your HTTP polling connections may be fine and well. But proxying long lived connections like HTTP Binding would quickly build up and defeat the beauty of it all.
Unless there is a proxy server that can handle 100’'s of open connections with a low impact on memory usage?
I really want to find a solution that works as great as HTTP binding was made to be.
I guess that you want to use one IP address and port 80 for Wildfire-HTTP-Bind and your existing Apache/PHP webserver. As far as I know Apache’'s mod_proxy (v2.2) uses a cache and thus is does not work for this purpose. This reminds me of Quercus, which execute PHP code within Java.
To use one IP address and port 80 for more than one server you may use a small layer 7 switch or give Squid as a reverse proxy a try.
One possible solution for you is to use Flash to bridge the gap to the other domain. It is fairly simple to get setup, here is an example of how this would work. There are many other examples of ways to handle cross domain ajax, proxy, and iframes (on the same subdomain).
Hey Alex, I was just talking to you in the weekly chat. Keep up the good work and don’'t get discouraged about the XMLHttpRequest limitations. An efficient solution will present itself eventually. Here is a software based layer 7 switch that I found that can route that requests based on URL:
Interesting link. I think that would work as long as your page wasn’'t already making AJAX calls. That should be fine for some applications that want to use HTTP binding, but will be a pain when you want to do a simple integration. Our goal for the Javascript library and UI components is that they “just work” without having to do a lot of fiddling with proxies, changing your existing pages, etc. The Flash applet proxy still seems like the best approach for that scenario, but the other techniques discussed in this thread will be good solutions for those willing to go to more work:
Setup a proxy in your web server to HTTP bind.
Set the domain frames as discussed in the link you posted.
Deploy an HTTP bind service into your webserver directly instead of using the one in Wildfire (although we’'re not sure how practical this will be yet vs doing the proxy).