Don,
You sounded confused by the results of your testing, and I was trying to
show you where there is correlation between your test results and the
Qooxdoo RPC framework. It sounds like you still don't agree that there
is some order to your results - that somehow the behavior is still
unexpected. I think I provided you with some explanations for how your
results are not entirely unexpected.
To be clear, I pulled all of your test instances and scenarios out of
the email and arranged them in a spreadsheet to be able to see these
"relationships" more clearly, and this told me that when the page URL
matched the RPC url in your tests, your setup worked correctly, except
when you set cross-Domain to TRUE (when it wasn't necessary). When the
URLs didn't match and cross-Domain was FALSE (8 of your test cases), it
failed because those instances could not be run as non-crossDomain
requests due to the mismatched URLs - they must be letter-for-letter
identical, not just equivalent in your DNS system. So, I think I
explained why eight of your tests failed and why you got six successful
results - do you at least agree with that?
So, we know there are scenarios in your testing that worked correctly.
As for the two failures in Test section #2, I was suggesting that in
running 24 different tests, you might have accidentally run a couple of
them with the wrong line of code in place, as I suspect the first two
instances in Test section #2, which returned "Unknown Status code"
should have matched results from the first two instances in Test section
#5, where you DID get a good response - everything about these two
different test scenarios is identical, so the results should have also
been identical. It seems to me that those four results are definitely
anomalous results in your testing and might deserve to be repeated for
confirmation. Do you agree with that?
Obviously, something is not working correctly for you with cross-domain
requests, and I suspect it has something to do with the fact that this
forces a different transport mode for the request. But, do you intend
on serving a Qooxdoo application from one server that accesses the RPC
backend on a different server? You haven't really made that clear. If
they always reside on the same server, then just make sure you form the
RPC url based on the webpage URL, and it should work fine. In this
case, don't worry about why cross-Domain requests aren't working.
If you really need to serve the RPC from a different URL address, then
you will need to work out the cross-Domain transport issue. From your
statements, it appears that your web2py backend may not be a factor in
your failures for cross-Domain RPC calls, but I can't confirm that for
you. If you trust the web2py ML answers, then maybe that's true.
However, I'm not at all familiar with web2py to give you any additional
insight into why cross-Domain requests are not working. I'm hoping
someone else on the ML can shed more light from their own experience
with web2py. Anyone else care to chime in here?
You may have to do more reading to understand Script Transport versus
XMLHttp transport mechanisms, which is what IS DIFFERENT when you try to
make the RPC call as a cross-domain request. It's obvious to me that
this deserves a closer look - if you really need to use cross-Domain
requests. Keep in mind that implementing cross-Domain requests comes
with additional security compromises, but if you must use them, then
you'll have to work through this issue. I have not had the pleasure of
digging this deeply myself, but hopefully Derrell or others on the ML
can shed more light on the key differences in the transports that might
be responsible for your failures.
Again, I don't know enough about web2py to help solve the cross-Domain
issue, but I hope I've clarified why I think your tests are actually
useful AND consistent, which seemed to be your original question.
See below for one additional comment relative to your client versus
server testing and some FQDN thoughts.
Best regards,
Gene
On Fri, 2009-10-23 at 23:17 -0400, Don Lee wrote:
> First let me say thank you for your response to my question. I will
> reply to each section.
>
> On Fri, Oct 23, 2009 at 7:39 PM, Gene Amtower <g...@pc-backup.com> wrote:
> > Don,
> >
> > First, I think there's a misunderstanding about what crossDomain means - it
> > does not refer to a "domain" in the sense of a domain name or network
> > domain. It is just used here to refer to a request to a different RPC URL
> > than the source page that makes the RPC request. Since you mentioned that
> > the client is in the same network domain as the server, it appears you may
> > have misinterpreted this terminology.
>
>
> I actually understood this point. My intention in stating the FQDN of
> my systems was that whether or not crossDomain was enabled, the
> requests made from the server should have worked.
I think it should be clear from your testing that the results didn't
matter whether you opened it in a browser on your client or a browser on
your server - in each pair of test cases (client versus server), the
results were identical between them. In each case, the rules for RPC
calls are still the same. Keep in mind that even when you open it in a
browser on the server, that it's still acting like a client, even if the
communication loop is a very small loop internal to the server. All the
same limitations apply to browser scripting in that case. So, don't
think that just because the browser window is on the same machine as the
server instance that it changes the rules - the Qooxdoo framework is not
so smart that it can bypass basic browser security limitations. And
finally, enabling the cross-Domain property FORCES a different transport
method, even if it wasn't warranted in that instance. Maybe you're
over-complicating the situation.
One additional comment relative to the FQDN versus NetBios name in your
requests - it would seem that you are only developing apps for use
within an Intranet environment; otherwise, using NetBios names in URLs
doesn't make much sense for the web. However, even in Intranet
situations, I always develop for FQDN URLs - maybe I just don't trust
NetBios naming to always work correctly. However, if you're developing
applications for the web, why are you doing any work with NetBios names?
>
> > Also, when you don't set crossDomain explicitly, it defaults to FALSE in the
> > implementation of qx.io.remote.RPC. So, I would expect your requests with
> > it set to FALSE to have the same result as your requests where you didn't
> > set it at all. In fact, they are the same between these two scenarios in
> > all except 4 of your tests in sections 2 & 5 - where your request came from
> > //server and your rpc call went to //server. Since you didn't show any code
> > from your app or remote service, it's not clear why these scenarios would be
> > different - Setting crossDomain to FALSE and not setting it at all should
> > have yielded the same result between #1, 2, 5, & 6. Maybe you made a
> > mistake somewhere in your testing, and these scenarios really would have had
> > the same result if done as you stated.
>
> [ -------------------------------------------- | Begin QooxDoo Code |
> -------------------------------------------- ]
> // Create a button
> var button1 = new qx.ui.form.Button("Submit");
>
> // create a text field to hold the e-mail address
> var emailField = new qx.ui.form.TextField();
> emailField.setWidth(140);
> var emailLabel = new qx.ui.basic.Label("e-mail address:");
>
> // setup rpc class
> var rpc = new qx.io.remote.Rpc();
> rpc.setTimeout(10000);
> rpc.setUrl("http://server.domain.com/app/controller/call/jsonrpc";);
> rpc.setServiceName("");
>
> // asynchronous call
> var handler = function(result, exc, id) {
> if (exc == null) {
> alert("Result of async call: " + result);
> } else {
> alert("Exception during async call: " + exc);
> }
> };
>
> // Document is the application root
> var doc = this.getRoot();
>
> // Add button to document at fixed coordinates
> doc.add(button1, {left: 100, top: 50});
> // Add email field to document root
> doc.add(emailLabel, {left: 100, top: 0});
> doc.add(emailField,{left: 175, top: 0});
>
> // Add an event listener
> button1.addListener("execute", function(e) {
> // asynchronous call
> rpc.callAsync(handler, "search", emailField.getValue());
> //rpc.callAsync(handler, "echo", "Test");
>
> [ -------------------------------------------- | End QooxDoo Code |
> -------------------------------------------- ]
>
> [ -------------------------------------------- | Begin Web2py Code |
> -------------------------------------------- ]
> import ldap
>
> server='ldap.domain.com'
> base_dn='ou=ldap,o=domain.com'
> search='mail'
>
> def index():
> redirect(URL(r=request,f='searchApp'))
>
> def searchApp():
> return dict()
>
> def call():
> # remove session.forget() if you want to use session cookies for services
> session.forget()
> return service()
>
> @service.jsonrpc
> def search(email="d...@domain.com"):
> dn = None
> search = 'email'
> filter = '('+search+'='+email+')'
> attrs = ['uid']
>
> con = ldap.initialize("ldaps://" + server + ":" + "636")
>
> result=con.search_s(base_dn, ldap.SCOPE_SUBTREE, filter)
> dn=result[0][0]
> return dn
>
>
> @service.jsonrpc
> def echo(msg):
> return msg
> [ -------------------------------------------- | End Web2py Code |
> -------------------------------------------- ]
>
>
> This app creates two callable service functions: echo(), and search().
> Echo simply returns what was sent to it. Search searches the ldap
> server and returns the distinguished name (dn). I have tested this
> from the python shell using jsonrpclib on both the server itself and
> on other machines. It worked.
>
>
> [ -------------------------------------------- | Begin Python Shell |
> -------------------------------------------- ]
> Python 2.4.3 (#1, Jul 27 2009, 17:56:30)
> [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import jsonrpclib
> >>> rpc =
> >>> jsonrpclib.ServerProxy("http://server.com/app/controller/call/jsonrpc";,
> >>> verbose=1)
> >>> print rpc.echo("Hello World!!")
> connect: (server, 80)
> send: 'POST /app/controller/call/jsonrpc HTTP/1.0\r\nHost:
> server\r\nUser-Agent: jsonlib.py/0.0.1 (by matt
> harrison)\r\nContent-Type: text/xml\r\nContent-Length: 56\r\n\r\n'
> send: '{"params": ["Hello World!!"], "method": "echo", "id": 3}'
> reply: 'HTTP/1.1 200 OK\r\n'
> header: Date: Sat, 24 Oct 2009 03:02:22 GMT
> header: Server: Apache/2.2.3 (Red Hat)
> header: Expires: Sat, 24 Oct 2009 03:02:22 GMT
> header: Pragma: no-cache
> header: Cache-Control: no-store, no-cache, must-revalidate,
> post-check=0, pre-check=0
> header: Set-Cookie:
> session_id_app=IP-89-8be806cc-e740-4f31-85da-500e9b45e7a1; Path=/
> header: Connection: close
> header: Content-Type: text/html; charset=UTF-8
> body: '{"error": null, "version": "1.1", "id": 3, "result": "Hello World!!"}'
> {u'result': u'Hello World!!', u'version': u'1.1', u'id': 3, u'error': None}
> >>>
> >>>
> >>>
> >>>
> >>> print rpc.search("d...@domain.com")
> connect: (server.domain.com, 80)
> send: 'POST /app/controller/call/jsonrpc HTTP/1.0\r\nHost:
> server.domain.com\r\nUser-Agent: jsonlib.py/0.0.1 (by matt
> harrison)\r\nContent-Type: text/xml\r\nContent-Length: 63\r\n\r\n'
> send: '{"params": ["d...@domain.com"], "method": "search", "id": 5}'
> reply: 'HTTP/1.1 200 OK\r\n'
> header: Date: Sat, 24 Oct 2009 03:06:00 GMT
> header: Server: Apache/2.2.3 (Red Hat)
> header: Expires: Sat, 24 Oct 2009 03:06:00 GMT
> header: Pragma: no-cache
> header: Cache-Control: no-store, no-cache, must-revalidate,
> post-check=0, pre-check=0
> header: Set-Cookie:
> session_id_app=IP-89c94dbe-9609-4c0e-96c5-fb47f5f450a2; Path=/
> header: Connection: close
> header: Content-Type: text/html; charset=UTF-8
> body: '{"error": null, "version": "1.1", "id": 5, "result":
> "uid=X-XXXXXXX,c=uk,ou=ldap,o=domain.com"}'
> {u'result': u'uid=X-XXXXXXX,c=uk,ou=ldap,o=domain.com', u'version':
> u'1.1', u'id': 5, u'error': None}
> >>>
>
> [ -------------------------------------------- | End Python Shell |
> -------------------------------------------- ]
>
>
> > In summary, when you access a page at one URL and request an RPC service at
> > a different URL, you are going to need to set crossDomain to true. This is
> > likely why eight of your requests came back as "Unknown Status code", since
> > these were all cases where the page URL did NOT match the RPC URL and you
> > essentially had crossDomain set to FALSE (half by setting it to FALSE and
> > half by leaving it at the default of FALSE).
> >
> > Secondly, you didn't mention how your RPC server is configured. In the case
> > of RPC-PHP, the RPC server is configured by default to only allow
> > non-cross-domain requests. If you haven't checked this setting, then this
> > would explain why your requests with crossDomain set to TRUE would fail.
> > The server is likely ignoring the crossDomain request because it's set to
> > not allow them. Also note that setting crossDomain to TRUE will force a
> > different request mode, as pointed out in the API docs for qx.io.remote.RPC,
> > specifically using scriptTransport mode. So, even if you have set the RPC
> > server to allow crossDomain requests, it is possible that the specific
> > request you are implementing cannot be done via RPC with crossDomain set to
> > TRUE - it really depends on what you are trying to send and receive in your
> > specific implementation.
>
> I sent a message to the web2py mailing list today asking is there was
> anything needed to allow for cross domain calls in it json-rpc setup.
> The answer was no. The python shell tests confirmed in my mind that
> the web2py backend was working properly.
>
> http://groups.google.com/group/web2py/browse_thread/thread/1b224f2206b816b5#
> >
> > Anyway, I hope some of what I've said here provides some additional insight
> > for you. Derrell, please correct anything I might have stated incorrectly
> > here, as you're the expert in this area.
> >
> > Regards,
> >
> > Gene
> >
> > On Fri, 2009-10-23 at 15:28 -0400, Don Lee wrote:
> >
> > I am using qooxdoo-0.8.3, along with web2py as my backend. My web
> > server and client are on the same network/domain. I have observer that
> > depending on the URL provided to the RPC object and whether I set
> > crossDomain, I get weird behavior even when running the software from
> > the web server itself. I have found the following:
> >
> > web server / json-rpc service host = server.domain.com / server
> > client resolves to client.domain.com (they are both in the same domain)
> >
> > 1.
> > -------
> > setting
> > var rpc = new
> > qx.io.remote.Rpc("http://server.domain.com/app/controller/call/jsonrpc";);
> > rpc.setCrossDomain(false);
> >
> > - connecting to http://server/qxapp/source from the client produces
> > "Transport error 0: Unknown status code"
> > - connecting to http://server/qxapp/source from the server produces
> > "Transport error 0: Unknown status code"
> > - connecting to http://server.domain.com/qxapp/source from the client
> > produces a positive response from the service
> > - connecting to http://server.domain.com/qxapp/source from the server
> > produces a positive response from the service
> >
> >
> > 2.
> > -------
> > setting
> > var rpc = new qx.io.remote.Rpc("http://server/app/controller/call/jsonrpc";);
> > rpc.setCrossDomain(false);
> >
> > - connecting to http://server/qxapp/source from the client produces
> > "Local error 1: Local time-out expired"
> > - connecting to http://server/qxapp/source from the server produces
> > "Local error 1: Local time-out expired"
> > - connecting to http://server.domain.com/qxapp/source from the client
> > produces "Transport error 0: Unknown status code"
> > - connecting to http://server.domain.com/qxapp/source from the server
> > produces "Transport error 0: Unknown status code"
> >
> >
> > 3.
> > -------
> > setting
> > var rpc = new
> > qx.io.remote.Rpc("http://server.domain.com/app/controller/call/jsonrpc";);
> > rpc.setCrossDomain(true);
> >
> > - connecting to http://server/qxapp/source from the client produces
> > "Local error 1: Local time-out expired"
> > - connecting to http://server/qxapp/source from the server produces
> > "Local error 1: Local time-out expired"
> > - connecting to http://server.domain.com/qxapp/source from the client
> > produces "Local error 1: Local time-out expired"
> > - connecting to http://server.domain.com/qxapp/source from the server
> > produces "Local error 1: Local time-out expired"
> >
> >
> >
> > 4.
> > -------
> > setting
> > var rpc = new qx.io.remote.Rpc("http://server/app/controller/call/jsonrpc";);
> > rpc.setCrossDomain(true);
> >
> > - connecting to http://server/qxapp/source from the client produces
> > "Local error 1: Local time-out expired"
> > - connecting to http://server/qxapp/source from the server produces
> > "Local error 1: Local time-out expired"
> > - connecting to http://server.domain.com/qxapp/source from the client
> > produces "Local error 1: Local time-out expired"
> > - connecting to http://server.domain.com/qxapp/source from the server
> > produces "Local error 1: Local time-out expired"
> >
> >
> > 5.
> > -------
> > setting
> > var rpc = new qx.io.remote.Rpc("http://server/app/controller/call/jsonrpc";);
> > ** do not call rpc.setCrossDomain()
> >
> > - connecting to http://server/qxapp/source from the client produces a
> > positive response from the service
> > - connecting to http://server/qxapp/source from the server produces a
> > positive response from the service
> > - connecting to http://server.domain.com/qxapp/source from the client
> > produces "Transport error 0: Unknown status code"
> > - connecting to http://server.domain.com/qxapp/source from the server
> > produces "Transport error 0: Unknown status code"
> >
> >
> > 6.
> > -------
> > setting
> > var rpc = new
> > qx.io.remote.Rpc("http://server.domain.com/app/controller/call/jsonrpc";);
> > ** do not call rpc.setCrossDomain()
> >
> > - connecting to http://server/qxapp/source from the client produces
> > "Transport error 0: Unknown status code"
> > - connecting to http://server/qxapp/source from the server produces
> > "Transport error 0: Unknown status code"
> > - connecting to http://server.domain.com/qxapp/source from the client
> > produces a positive response from the service
> > - connecting to http://server.domain.com/qxapp/source from the server
> > produces a positive response from the service
> >
> >
> > I would think that at the very least, running the code from the server
> > would always produce positive results. That does not appear to be the
> > case, at least in my setup. Can anyone shed some light?
> >
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > qooxdoo-devel mailing list
> > qooxdoo-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> >
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > qooxdoo-devel mailing list
> > qooxdoo-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> >
> >
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
