jijo-paulose / node-xmpp-bosh

Automatically exported from code.google.com/p/node-xmpp-bosh
0 stars 0 forks source link

Allow BOSH connections trough GET vars #7

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hi!

Just reporting a feature I will soon try to implement to node-xmpp-bosh.

We are using a hack for BOSH cross-domain access using IE and Opera (inclusion 
of a <script /> element with the BOSH data in a GET var). It works pretty well, 
but it requires a self-made BOSH proxy PHP script. Too heavy... (5Mio 
RAM/request)

That's why I think implementing this hack to NXB may be really useful 
(particularly for our Jappix official service), without having lots of code to 
do (just a new handler, and a new method to serve the response packets).

If you want to have a look to our PHP script: 
http://codingteam.net/project/jappix/browse/trunk/php/bosh.php

Thanks, keep up the great work!

Original issue reported on code.google.com by vanaryon on 25 May 2011 at 4:17

GoogleCodeExporter commented 9 years ago
Great! So, the request will come in via the data= parameter and if cb= is 
present then it would do a JSONP?

This would be a good time to refactor the code base to include response handler 
in the BOSH session state so that the response issues (how to send) can be 
handled by that function itself.

Original comment by dhruvb...@gmail.com on 26 May 2011 at 7:29

GoogleCodeExporter commented 9 years ago
Yes, that's it. If a callback integer is provided in the GET vars, NXB will add 
it to the reply so that the browser can know which packet match with which 
request.

I think it is better you code it. My code will not be really optimized for long 
term development, because I don't know how you work on the code of NXB. ;)

Original comment by vanaryon on 26 May 2011 at 3:56

GoogleCodeExporter commented 9 years ago
That's okay, I think you are bringing about important points here and would be 
able to give better inputs since you've already worked on this thing. So thus, 
far, there are 2 things:

1. data= GET parameter (request body)
2. cb= GET parameter (function(response))

Example request:

GET /http-bind/?data=<body/>&cb=boshcb HTTP/1.1
Host: localhost

Example resoponse:

HTTP/1.1 200 OK
Content-Length: XX

boshcb('<body type="terminate" condition="item-not-found"/>')

Is this interaction enough to cover all use-cases?

Original comment by dhruvb...@gmail.com on 26 May 2011 at 6:16

GoogleCodeExporter commented 9 years ago
That's it. The callback can also be an integer with a string, such as cb34, 
which will give the following JSON output:

cb34({JSON ENCODED XML REPLY});

You can find the client side callback manager, if it helps you: 
http://codingteam.net/project/jappix/browse/trunk/js/jxhr.js#line-77

Original comment by vanaryon on 26 May 2011 at 7:07

GoogleCodeExporter commented 9 years ago
Hey, after investigating this, it seems there are a lot of differences between 
the GET and POST method ways of getting the data (the former is QS based and 
the latter is body based). I think that a cleaner (and more performant) way 
would be to run another http server that only intercepts GET requests and 
forwards them as POST requests to the POST handler (sort of internal redirect). 
And it's quite simple to do in node. I think that an option to enable this 
would be good. Will write this as a separate module.

Original comment by dhruvb...@gmail.com on 28 May 2011 at 8:36

GoogleCodeExporter commented 9 years ago
Okay great!
Thanks for this ;)

Original comment by vanaryon on 28 May 2011 at 8:46

GoogleCodeExporter commented 9 years ago
Actually, ignore my previous comments. I was unnecessarily complicating the 
whole thing. Have pushed commit #239 for this. Do let me know if it works for 
you.

Example:
http://localhost:5280/http-bind/?data=%3Cbody%20sid=%22aab%22%20/%3E&cb=vanaryon
http://localhost:5280/http-bind/?data=%3Cbody%20sid=%22aab%22%20/%3E

Original comment by dhruvb...@gmail.com on 28 May 2011 at 9:44

GoogleCodeExporter commented 9 years ago
The only difference is that it doesn't return a JSON encoded XML response, but 
instead returns the XML response as a string - same format as the POST request.

Original comment by dhruvb...@gmail.com on 28 May 2011 at 9:53

GoogleCodeExporter commented 9 years ago
Mhh, maybe callback instead of cb var is better. And is the sid var necessary 
to connect? Or just something additional?

Will test it tomorrow, Thanks!

Original comment by vanaryon on 28 May 2011 at 2:56

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r240.

Original comment by dhruvb...@gmail.com on 28 May 2011 at 3:14

GoogleCodeExporter commented 9 years ago
Commit #240 should accept "callback" instead of "cb".
sid MUST not be sent in the first request, but subsequent requests MUST set it 
to the value returned by the server in the first request.

Original comment by dhruvb...@gmail.com on 28 May 2011 at 3:16

GoogleCodeExporter commented 9 years ago
Great, I will make some change to jxhr.js for this!

Original comment by vanaryon on 28 May 2011 at 3:27

GoogleCodeExporter commented 9 years ago
That's strange, I don't see any 'sid' GET var handler in the code, so, why MUST 
this var be set?

Anyway, the SID value is sent in the XML, with <body sid="" />, so I don't 
understand why it is required in the URL?

Original comment by vanaryon on 29 May 2011 at 8:33

GoogleCodeExporter commented 9 years ago
> Anyway, the SID value is sent in the XML, with <body sid="" />, so I don't 
understand why it is required in the URL?

I thought you were referring to the XML request <body>-tag.

If you meant in the GET parameters, then nothing extra is needed. Whatever you 
pass in the POST body would be passed in as the data=XX param (XX is the POST 
body). Optionally, if callback=YY is passed, the response will be returned as 
YY("response");

Is that okay??

Original comment by dhruvb...@gmail.com on 29 May 2011 at 9:05

GoogleCodeExporter commented 9 years ago
Okay, we misunderstood ourselves. Your previous comment (comment 7) mentioned 
the 'sid' var, I thought you needed it to be passed as an URL var for technical 
reasons.

No problem for the other things, it's okay!

I will test if it works ASAP and let you know if it works ;)

Original comment by vanaryon on 29 May 2011 at 9:20

GoogleCodeExporter commented 9 years ago
ah! I'm glad that confusion is resolved ;)

Original comment by dhruvb...@gmail.com on 29 May 2011 at 9:24