Hi Jim,
Am 09.10.2007 um 03:23 schrieb Jim Hunter:
> I guess I am a bit confused... I should not have to call
> _requestFinished as this is an internal function.
Well, not quite. It's internal in the sense that you shouldn't call
it from JS code. The server-generated code can be considered p
On 10/8/07, Andreas Junghans <[EMAIL PROTECTED]> wrote:
>
> Hi Jim,
>
>
> That's because Script transport expects your code to do something
> specific :-) It has to look like this:
>
> qx.io.remote.ScriptTransport._requestFinished("id", "My content");
>
> The id must be the one sent to the server
Hi Jim,
Am 08.10.2007 um 23:45 schrieb Jim Hunter:
> OK, assuming that I want to adhere to the cross-domain rules, I
> have a file on a publicly available web site (you can test on this
> file if you like) that is a simple text file (do I need to rename
> it to a JS extension?) with a singl
Hi Derrell,
Am 09.10.2007 um 00:01 schrieb Derrell Lipman:
> On 10/8/07, Andreas Junghans <[EMAIL PROTECTED]> wrote:
>> OK, I think I get it. You're right, there's no security problem
>> (since you can't load arbitrary content without preparing the
>> server). It seems like a nice idea for applic
On 10/8/07, Andreas Junghans <[EMAIL PROTECTED]> wrote:
> OK, I think I get it. You're right, there's no security problem
> (since you can't load arbitrary content without preparing the
> server). It seems like a nice idea for applications from different
> domains to communicate with each other (an
Hi Jim,
Am 08.10.2007 um 22:34 schrieb Andreas Junghans:
> I understand what you're trying to do, but it's just not possible -
> not with Script transport nor with anything else we could come up
> with (except for exploits for security holes ...).
Small correction: It's not _entirely_ impossible
Hi Jim,
Am 08.10.2007 um 22:14 schrieb Jim Hunter:
> Under the covers it might be using a Script transport but that is
> not what I intended. Here is the code I am using:
>
> var rpc = new qx.io.remote.Request();
> rpc.setResponseType('text/plain');
> rpc.setUrl("http://www.solumina
Under the covers it might be using a Script transport but that is not what I
intended. Here is the code I am using:
var rpc = new qx.io.remote.Request();
rpc.setResponseType('text/plain');
rpc.setUrl("http://www.solumina.com/webexpress/showme2.txt";);
rpc.setCrossDomain(true);
Hi Derrell,
Am 08.10.2007 um 21:41 schrieb Derrell Lipman:
>> @Derrell: I would be very interested in the other transport method
>> you mentioned in this thread (something about fragment identifiers).
>> While Script transport is quite usable, another alternative would be
>> nice. However, if it
On 10/8/07, Andreas Junghans <[EMAIL PROTECTED]> wrote:
> The MIME type doesn't matter here - the Script transport just works
> differently than the other transports (and it has to because of
> security limitations).
Yeah, duh. :-) For some reason, I forgot he was using Script
transport, although
Hi there,
Am 08.10.2007 um 20:50 schrieb Derrell Lipman:
> On 10/8/07, Jim Hunter <[EMAIL PROTECTED]> wrote:
>> I have one question... why does qooxdoo execute a text file when
>> it is
>> returned via qx.io.remote.Request? The file has a TXT extension
>> and the
>> header says that it is of
On 10/8/07, Jim Hunter <[EMAIL PROTECTED]> wrote:
> I have one question... why does qooxdoo execute a text file when it is
> returned via qx.io.remote.Request? The file has a TXT extension and the
> header says that it is of type 'text/plain', so why does qooxdoo
> execute/eval the content of the f
I have one question... why does qooxdoo execute a text file when it is
returned via qx.io.remote.Request? The file has a TXT extension and the
header says that it is of type 'text/plain', so why does qooxdoo
execute/eval the content of the file? I should be able to simply download a
file for later
It was a typo, it was 'text/plain' that I specified. I don't admin the
server so I am not 100% sure what it is actually specifying as the mime
type, that is why I was forcing it to 'text/plain'. So it looks like the
transport is not handling the 'text/plain' correctly or the server is not
sending t
On 10/6/07, Jim Hunter <[EMAIL PROTECTED]> wrote:
>
> Good information but I see that the script transport does support text
> only. I tried to set the response type to text/PLAIN but it didn't like it,
> got the same error message. So what type of text does it like? Or is it a
> requirement that t
Good information but I see that the script transport does support text only.
I tried to set the response type to text/PLAIN but it didn't like it, got
the same error message. So what type of text does it like? Or is it a
requirement that the file have a .txt extension?
I would be happy to help sol
On 10/5/07, Jim Hunter <[EMAIL PROTECTED]> wrote:
> I have been playing with trying to get a cross domain request to work for
a
> few hours now with no success. I created a request, and loaded a local
file
> and it does what I want it to do. But as soon as I change the URL to a
> remote location an
I have been playing with trying to get a cross domain request to work for a
few hours now with no success. I created a request, and loaded a local file
and it does what I want it to do. But as soon as I change the URL to a
remote location and set the CrossDomain to true, I always get:
ERROR: qx.io
18 matches
Mail list logo
