Re: HTML_AJAX cookies
| From: | Joshua Eichorn | Date: | Mon, 17 Oct 2005 16:56:30 +0000 |
| Subject: | Re: HTML_AJAX cookies | ||
| References: | 1 2 3 4 5 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-21512@lists.php.net to get a copy of this message | ||
Ken Restivo wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Oct 14, 2005 at 09:25:47AM -0700, Joshua Eichorn wrote:I guess grab could be updated to use a GET method but the default is requestType is actually POST and it doesn't override that. That looks like a 405 error from your Apache server since its not allowing POST requests to an HTML page. I decided to punt, and just require cookies to be on in order to use this part of the app. But I do need to fix this. I checked, and indeed if there's a ? in the URL, HTML_AJAX loses its mind. If I get time I'll generate a minimum test case to break it, and submit a bug report, or just fix it and submit a patch.Ken Restivo wrote:OK that was pilot error on my part: my app uses SID so that it works if cookies were off, so I didn't realise I'd blocked them in the profile I use for testing. Thanks for your help. Couple of other issues: 1) Looks like grab() uses GET method? If I grab('foo.php'), everything works fine. If I grab('foo.html'), I get: Error: [Exception... "'Error: HTTP Error Making Request: [405] Method Not Allowed' when calling method: [nsIOnReadystatechangeHandler::handleEvent]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "<unknown>" data: no]-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Oct 13, 2005 at 04:14:46PM -0700, Joshua Eichorn wrote:Cookies have always just worked for me, what browser are you using. -joshKen Restivo wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm fixing to use HTML_AJAX to add a database-driven subclasses of QF heirselect. One thing that is perplexing me, is trying to get HTML_AJAX's javascript to use the cookie (and resulting SESSION vars and auth tokens) I've already established when loading the parent page. Any ideas? Cookies are one of those things I'd expect would "just work", but apparently some configuration is required. - -ken
I see. This appears to be a scope problem in Javascript Shell. HTML_AJAX.defaultServerUrl is defined in the top-level script, but apparently the Javascript Shell has some weird context issue in which it doesn't see that. I'll take it up with the Javascript Shell maintainers.2) I'm pretty dependent on the JavaScript Shell 1.0 which is included in the Extension Developers extension. I use it from its own JavaScript Shell interface as well as from within emacs using js-mode.el. From the JavaScript Shell, the clearTarget(), replaceUrl(), and grab[A]Sync() functions from your proxyless test work perfectly. But if I try to run the callSync() or callAsync() functions, I get: Security Error: Content at http://www/coop-dev/tests/jsontest.php may not load or link to resource://gre/res/jsonservertest.php?c=test&m=echo_string. Any idea where the URL "resource://gre/res" came from?Your url got messed up, try using a full url when using grab. I've only had that problem when combining AJAX and flash-javascript integration, but im sure other things can get firefox into a confused state.
Looks like this failure condition was due to problem (2) above. Venkmann reports the error in a different way from Javascript Shell.3) So I tried from inside Venkmann instead. Just as from within JavaScript Shell, clearTarget(), replaceUrl(), and grab[A]Sync() work great, but callSync() dies a different death: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.setRequestHeader]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://www/coop-dev/tests/jsonservertest.php?client=HttpClient :: anonymous :: line 79" data: no] That line 79 in httpClient is inside makeRequest(), specifically: this.xmlhttp.setRequestHeader('Content-Type',this.request.getContentType()). So in Venkmann I'm not getting complaints about the security, but it is puking on setRequestHeader().I'm not sure what the deal is here, the XMLHttpRquest docs don't document what its failure conditions are.
It's a scope issue, like (1) above. Emacs has no problem with it, but the commands it sends to Javascript Shell are running in some weird scope-- that of the Javascript Shell page itself, not of my target page. So of course it has no reference to HTML_AJAX. I have no idea why the Javascript Shell has access to the context of the target page, but the socket listener it opens for Emacs to connect to, does not. I'll take this up with the Javascript Shell maintainers.4) Yet another obstacle blocking my path, is that from within emacs I can inspect objects like document, etc. But I get "ReferenceError: HTML_AJAX is not defined" if I try to inspect HTML_AJAX. But if from within the JavaScript Shell, I evaluate "a=HTML_AJAX", then I can inspect that objectfrom within emacs! It doesn't seem to be a reference copy, but rather a*new* HTML_AJAX instance, strangely enough. It looks to me like HTML_AJAX is a class and 'a' is an instance, even though both JavaScript Shell and Venkmann report them both as [object Object].HTML_AJAX isn't a real javascript object is a hash of functions you can use statically. I'm not sure why emacs doesn't like that.
I have one more question then :-) I'm trying to call remote procedures using HTML_AJAX and JSON and having no luck. I've got an HTML_AJAX server and client working (thanks to your help!). In the client, I can call a remote function that returns a remote object, and inspect its object vars (yay!), but I don't see any of its methods listed. I can'seem to execute any of its methods either. i.e. remobj = HTML_AJAX.call('test','userobj', false, 'useless arg'); remobj.someFunction(); // doesn't work I guess I've read enough of the jsolait docs to be confused-- I thought there was a way to do this but maybe I'm missing something. Check out the examples dir, that now how HTML_AJAX works. You can either use HTML_AJAX in proxy mode or proxyless. HTML_AJAX.call is proxyless, it just returns results. If you want proxied operation you include a stub server.php?stub=classname and then you can just do remobj = new classname(new callbackClass); and call its methods. -joshAt this point it doesn't look like PEAR problems, but rather JavaScript issues, specifically interactions between HTML_AJAX and Venkmann and/or JavaScript Shell. If I should take this off-list please let me know, though other users of the package may run into these problems too.On list is fine with me, as long as no one on pear-general complains about the noise.
- -ken - -- - --------------- The world's most affordable web hosting. http://www.nearlyfreespeech.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDUbbGe8HF+6xeOIcRAlMUAKCViVzdiUgN/d0HyA/oCTylDTET3wCfWY/9 vGww8ciLn+qiw3qw5jQLjvY= =q7h7 -----END PGP SIGNATURE-----