The problem is that many formats can't detect that they have been cut
off. Even for something as strict as XML you could be loosing comments
and PIs at the end of the document if the transation is terminated.
The reason responseXML would be null in mozilla is that we'd get an
internal error-n
Jim Ley wrote:
"Christophe Jolif" <[EMAIL PROTECTED]>
Even though you can always imagine to find solution to workaround it.
I think it is a bad idea to go to 4 without having a clear knowledge
of what the status really is (successful or erroneous). Indeed bad or
null XML can be due to a bug
"Christophe Jolif" <[EMAIL PROTECTED]>
Even though you can always imagine to find solution to workaround it. I
think it is a bad idea to go to 4 without having a clear knowledge of what
the status really is (successful or erroneous). Indeed bad or null XML can
be due to a bug on the server, no
Jim Ley wrote:
"Jonas Sicking" <[EMAIL PROTECTED]>
In IE you can at least test for .status == 200 to test if things
worked out ok. Even though the statuscode for various errors seem to
be weird to say the least, at least they are different from the
success codes.
I actually think this is h
"Jonas Sicking" <[EMAIL PROTECTED]>
The problem is that many formats can't detect that they have been cut off.
Even for something as strict as XML you could be loosing comments and PIs
at the end of the document if the transation is terminated. The reason
responseXML would be null in mozilla
If we do go to state 4 then things will look almost exactly like a
successful response. The only difference is that .responseXML will be
null, but that is already the case for a lot of consumers that send
non-xml data.
I'd sort of disagree, the problem will manifest itself by the result not
"Jonas Sicking" <[EMAIL PROTECTED]>
In IE you can at least test for .status == 200 to test if things worked
out ok. Even though the statuscode for various errors seem to be weird to
say the least, at least they are different from the success codes.
I actually think this is how we should do er
Jonas Sicking wrote:
In IE you can at least test for .status == 200 to test if things worked
out ok. Even though the statuscode for various errors seem to be weird
to say the least
I believe they're just the relevant WinINet error codes. See
https://bugzilla.mozilla.org/show_bug.cgi?id=3049
Jim Ley wrote:
"Jonas Sicking" <[EMAIL PROTECTED]>
Why do we need to find a solution for error handling? I thought that
wasn't necessary for "version 1.0".
Not having error handling at all will seriously cripple the usefulness
of the spec.
We've survived so far without error handling othe
"Jonas Sicking" <[EMAIL PROTECTED]>
Why do we need to find a solution for error handling? I thought that
wasn't necessary for "version 1.0".
Not having error handling at all will seriously cripple the usefulness of
the spec.
We've survived so far without error handling other than magic (and
Why do we need to find a solution for error handling? I thought that
wasn't necessary for "version 1.0".
Not having error handling at all will seriously cripple the usefulness
of the spec. Of course, we could rely on that authors have sufficient
control over the server and client side to mak
On Fri, 07 Apr 2006 09:34:03 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
Actually, the last mail I see from anyone on this subject is Jim Lay
arguing for always going to 4, which I tend to agree with as long as we
can find some solution for error handling.
From what I recall the last e-
Anne van Kesteren wrote:
On Thu, 06 Apr 2006 11:20:53 +0200, Christophe Jolif <[EMAIL PROTECTED]>
wrote:
As far as I can see, dispatching another event will not permit to
distinguished between readyState = 4 that means LOADED and readyState
= 4 that means ABORTED...
Per our last reso
Anne van Kesteren wrote:
On Thu, 06 Apr 2006 11:28:09 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
If that is indeed true we need to fix it I agree. Is there a
sensible value we could set .status to for example?
Lets keep .status an HTTP status code. What about dispatching an
abort e
Anne van Kesteren wrote:
On Thu, 06 Apr 2006 11:20:53 +0200, Christophe Jolif <[EMAIL PROTECTED]>
wrote:
As far as I can see, dispatching another event will not permit to
distinguished between readyState = 4 that means LOADED and readyState
= 4 that means ABORTED...
Per our last resolution .
On Thu, 06 Apr 2006 11:20:53 +0200, Christophe Jolif <[EMAIL PROTECTED]>
wrote:
As far as I can see, dispatching another event will not permit to
distinguished between readyState = 4 that means LOADED and readyState =
4 that means ABORTED...
Per our last resolution .abort() mean cancel al
On Thu, 06 Apr 2006 11:28:09 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
If that is indeed true we need to fix it I agree. Is there a sensible
value we could set .status to for example?
Lets keep .status an HTTP status code. What about dispatching an abort
event on the object as I sugge
Anne van Kesteren wrote:
On Wed, 05 Apr 2006 22:56:28 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
If that is indeed true we need to fix it I agree. Is there a sensible
value we could set .status to for example?
Lets keep .status an HTTP status code. What about dispatching an abort
event
Hi,
Anne van Kesteren wrote:
On Wed, 05 Apr 2006 22:56:28 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
If that is indeed true we need to fix it I agree. Is there a sensible
value we could set .status to for example?
Lets keep .status an HTTP status code. What about dispatching an abort
On Wed, 05 Apr 2006 22:56:28 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
If that is indeed true we need to fix it I agree. Is there a sensible
value we could set .status to for example?
Lets keep .status an HTTP status code. What about dispatching an abort
event on the object as I sugge
Christophe Jolif wrote:
Hi everyone,
There is something I still don't get with abort and XHR state. We saw
that we think the state after an abort must be 4 == loaded. Given that,
as a listener on the request, how can I know if a request has been
aborted or has been loaded? As far as I can s
On Wed, 05 Apr 2006 15:14:18 +0200, Christophe Jolif <[EMAIL PROTECTED]>
wrote:
There is something I still don't get with abort and XHR state. We saw
that we think the state after an abort must be 4 == loaded. Given that,
as a listener on the request, how can I know if a request has been
Hi everyone,
There is something I still don't get with abort and XHR state. We saw
that we think the state after an abort must be 4 == loaded. Given that,
as a listener on the request, how can I know if a request has been
aborted or has been loaded? As far as I can see, I can't. And it seems
"Jonas Sicking" <[EMAIL PROTECTED]>
1. Always go to 4 when abort is called
We have done 1 in mozilla for years and no one (until the other week) has
complained. So by that I would draw the conclusion that that is safe to
do, however I reasoned the same way when it came to send-with-no-argum
Anne van Kesteren wrote:
On Mon, 03 Apr 2006 18:05:56 +0200, Jim Ley <[EMAIL PROTECTED]> wrote:
The decision at the f2f was that the going to 4 was relied on by
people, used in situations such as hiding the "please wait" etc. I
think this should continue to be the resolution.
That doesn't
Boris Zbarsky wrote:
Please see the remainder of that thread, and in particular see
http://groups.google.com/group/mozilla.dev.tech.xml/tree/browse_frm/thread/74257e17b66e68e8/8e0b8aded9bac4a0?rnum=1&_done=%2Fgroup%2Fmozilla.dev.tech.xml%2Fbrowse_frm%2Fthread%2F74257e17b66e68e8%2F8e0b8aded9bac4a
On Mon, 03 Apr 2006 18:05:56 +0200, Jim Ley <[EMAIL PROTECTED]> wrote:
The decision at the f2f was that the going to 4 was relied on by people,
used in situations such as hiding the "please wait" etc. I think this
should continue to be the resolution.
That doesn't reflect what IE does.
-
"Boris Zbarsky" <[EMAIL PROTECTED]>
Anne van Kesteren wrote:
Do you have any input?
Not particularly, no. I think we'd be happy to change our behavior too,
as needed, but I have no idea whether anyone depends on IE's behavior,
etc.
The decision at the f2f was that the going to 4 was reli
Anne van Kesteren wrote:
Do you have any input?
Not particularly, no. I think we'd be happy to change our behavior too, as
needed, but I have no idea whether anyone depends on IE's behavior, etc.
-Boris
On Mon, 03 Apr 2006 17:46:11 +0200, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
[...] and the bug referenced therein, which describes IE's behavior. IE
does set the readyState to 4 in some cases, but not in others,
apparently.
Interesting. I guess the WG descision was made based on the case wh
Web APIs Issue Tracker wrote:
http://groups.google.com/group/mozilla.dev.tech.xml/browse_thread/thread/74257e17b66e68e8/8e0b8aded9bac4a0
points out that only Mozilla has a funny implementation like that where all
other implementations just reset the object.
Please see the remainder of that thr
ISSUE-58: XMLHttpRequest.abort() should just reset the object
http://www.w3.org/2005/06/tracker/webapi/issues/58
Raised by: Anne van Kesteren
On product: XMLHttpRequest
For some reason we resolve that abort() should do:
Calling this method MUST cancel any network activity for which
the
32 matches
Mail list logo
