According to HTTP/1.1 specs, a client should only have two connections open
to the host at a time (which can be changed by browser users, of course).
When using xmlHttpRequest connections, is there any way to detect that the
request is queued?
I did some tests (see "Queued Requests" at http://www.ajaxtoolbox.com/request/examples.php ) and it looks like
readyState 1 is fired immediately after the request is made, even though
it's not actually active yet.
Is there anything else I can look at to tell if my request has been queued
and hasn't actually started running yet?
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com 25  11074 
Matt Kruse wrote: According to HTTP/1.1 specs, a client should only have two connections
open to the host at a time (which can be changed by browser users, of
course).
Not quite.
,-[RFC2616: <URL:http://rfc-editor.org/rfc/rfc2616.txt>]
|
| 8.1.4 Practical Considerations
| [...]
| A single-user client SHOULD NOT maintain more than 2 connections with
| any server or proxy. [...]
And that is only a SHOULD NOT, not a MUST NOT. For HTTP/1.1 clients, not
for HTTP/1.0 clients. Therefore, it may even happen without the user
interfering.
When using xmlHttpRequest connections, is there any way to detect that
the request is queued?
^^^^^^
What do you mean by that? AFAIK, you can only make one request with one
XMLHTTPRequest object at a time (see [1]). A Web server may (and probably
will) fork a child process per connection (e.g. Apache2 prefork MPM), and
those child processes may create threads per connection (e.g. Apache2
worker MPM); but the client cannot know about that.
I did some tests (see "Queued Requests" at
http://www.ajaxtoolbox.com/request/examples.php ) and it looks like
readyState 1 is fired immediately after the request is made, even
though it's not actually active yet.
Of course XMLHTTPRequest::readyState is 1 the first time
XMLHTTPRequest::onreadystatechange is called. What do you mean by
"not actually active"? If you mean that the actual HTTP request was
not made yet, you are looking for readystate == 2 (LOADED) instead.
See also
<URL:http://msdn.microsoft.com/library/en-us/xmlsdk/html/0e6a34e4-f90c-489d-acff-cb44242fafc6.asp>
<URL:http://xulplanet.com/references/objref/XMLHttpRequest.html>
BTW: I get
| Error: this.form has no properties
| Source file: http://www.ajaxtoolbox.com/request/examples.php
| Line: 1
(in Firefox 1.5.0.1/Linux) when I click one of the buttons in the
"Simultaneous Requests" section.
BTW 2: I have had to review important parts of your library now (using the
commented version), and I do think that I am going to write my own XMLHTTP
request library, unless something better comes along. I dislike your
creating a new AjaxRequest object needlessly when calling
AjaxRequest.doRequest(), for example.
HTH
PointedEars
___________
[1] news:12****************@PointedEars.de
Thomas 'PointedEars' Lahn wrote: A single-user client SHOULD NOT maintain more than 2 connections with
any server or proxy. [...] And that is only a SHOULD NOT, not a MUST NOT.
Which is exactly what I said. Should. Not must.
For HTTP/1.1 clients,
not for HTTP/1.0 clients.
I believe 1.0 recommended a max of 4 connections. I don't remember.
When using xmlHttpRequest connections, is there any way to detect
that the request is queued?
^^^^^^
What do you mean by that?
Queued by the client. It has nothing to do with the server.
If a client maintains only two connections with the server at a time, then
trying to open a third connection will cause it to wait until one of the
other two is finished.
Of course XMLHTTPRequest::readyState is 1 the first time
XMLHTTPRequest::onreadystatechange is called. What do you mean by
"not actually active"? If you mean that the actual HTTP request was
not made yet, you are looking for readystate == 2 (LOADED) instead.
readyState 1 means "loading". Which is misleading. Because if the request is
queued, then it hasn't actually started loading yet. I would have expected
these requests to stay in readyState 0 until they actually opened a
connection to the server. ReadyState 2 means loaded, meaning the content has
been delivered. That is certainly not what I want.
BTW: I get Error: this.form has no properties
Source file: http://www.ajaxtoolbox.com/request/examples.php
Line: 1 (in Firefox 1.5.0.1/Linux) when I click one of the buttons in the
"Simultaneous Requests" section.
Thanks for letting me know - fixed it. I screwed some things up while
updating the page this morning for the Queued example.
BTW 2: I have had to review important parts of your library now
(using the commented version), and I do think that I am going to
write my own XMLHTTP request library, unless something better comes
along. I dislike your creating a new AjaxRequest object needlessly
when calling AjaxRequest.doRequest(), for example.
I had considered pooling the objects and reusing them. However, my own tests
didn't show much speed improvement, if any. So for now I am not re-using
objects. If that's the only concern, then that's not too bad ;)
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
On 20/03/2006 21:41, Thomas 'PointedEars' Lahn wrote: Matt Kruse wrote:
[snip] When using xmlHttpRequest connections, is there any way to detect that
the request is queued?
^^^^^^
What do you mean by that? AFAIK, you can only make one request with one
XMLHTTPRequest object at a time [...].
Yes, but I believe that Matt is referring to the creation and
simultaneous use of multiple objects.
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Matt Kruse wrote:
[restored quotation level] Thomas 'PointedEars' Lahn wrote: Matt Kruse wrote: According to HTTP/1.1 specs, a client should only have two connections
open
to the host at a time (which can be changed by browser users, of
course). | A single-user client SHOULD NOT maintain more than 2 connections with
| any server or proxy. [...]
And that is only a SHOULD NOT, not a MUST NOT.
Which is exactly what I said. Should. Not must.
"should only ..." and "SHOULD NOT ... more than ..." have different meaning,
even if the "should" is capitalized.
For HTTP/1.1 clients,not for HTTP/1.0 clients.
I believe 1.0 recommended a max of 4 connections. I don't remember.
There is nothing in RFC1945 to support that. Probably you have confused
this with
| 1.3 Overall Operation
|
| [...] A tunnel acts as a relay point between two connections
| without changing the messages; tunnels are used when the
| communication needs to pass through an intermediary (such as a
| firewall) even when the intermediary cannot understand the contents
| of the messages.
|
| request chain -------------------------------------->
| UA -----v----- A -----v----- B -----v----- C -----v----- O
| <------------------------------------- response chain
|
| The figure above shows three intermediaries (A, B, and C) between the
| user agent and origin server. A request or response message that
| travels the whole chain must pass through four separate connections.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When using xmlHttpRequest connections, is there any way to detect
that the request is queued?
^^^^^^
What do you mean by that?
Queued by the client. It has nothing to do with the server.
If a client maintains only two connections with the server at a time, then
trying to open a third connection will cause it to wait until one of the
other two is finished.
That does not have anything with the readyState, though. The additional
HTTP connection is not opened when the XMLHTTPRequest object is created
or its open() method is called. It is opened when send() is called and
a sufficient number of arguments are provided for it. This is not only
theory; I have tested this myself with Firefox 1.5.0.1/Linux and running
`netstat -talpeen' in a tight loop in parallel.
Of course XMLHTTPRequest::readyState is 1 the first time
XMLHTTPRequest::onreadystatechange is called. What do you mean by
"not actually active"? If you mean that the actual HTTP request was
not made yet, you are looking for readystate == 2 (LOADED) instead.
readyState 1 means "loading". Which is misleading.
Complain to Micro$~1. They are also to blame for the fact that you have
to create a closure when using onreadystatechange.
because if the request is queued, then it hasn't actually started loading
yet.
Requests do not load, they are made. "Loading/-ed" refers to the object.
I would have expected these requests to stay in readyState 0 until
they actually opened a connection to the server. ReadyState 2 means
loaded, meaning the content has been delivered.
Not according to the MSDN Library, XULPlanet, my expectations, and
experience. readyState == 4 means the content has been delivered,
3 means that status code and headers have been received, 2 means
that send() was called (and therefore the HTTP request was made,
or "queued"), and 1 means that open() was called.
PointedEars
On 20/03/2006 22:03, Matt Kruse wrote:
[snip] I believe 1.0 recommended a max of 4 connections. I don't remember.
As I said in a previous thread, I don't believe that there are any
recommended limits for non-persistent connections. At least not in RFCs
1945 (HTTP/1.0) and 2616 (HTTP/1.1). What has been mentioned so far only
applies to persistent connections.
[snip]
If a client maintains only two connections with the server at a time,
then trying to open a third connection will cause it to wait until
one of the other two is finished.
Not necessarily. It depends upon the established capabilities of both
the client and server, as well as the form in which both requests and
responses are made.
If persistent connections are not in use (HTTP/1.0 without extensions,
or a HTTP/1.1 agent that has opted out), a third connection will
probably be opened assuming that the client hasn't established a number
of other connections for other purposes (downloading images, for example).
If persistent connections are in use, the client may attempt to pipeline
the new request; to send another request without waiting for the
response from the first. If it doesn't, then a connection will be reused
for the third request.
If the request method is non-idempotent, pipe lining should not be used.
If either a request or response has an entity body and is missing the
Content-Length header, the connection will be closed to mark the end of
that entity, necessitating the establishment of a new connection.
In all likelihood, the request will be queued. As I understand it, pipe
lining isn't utilised that much due to buggy implementations both
client- and server-side, and the vast majority of HTTP agents should use
v1.1 and support persistent connections. Of course, as noted above, how
a request or response is formed can still affect the efficiency of HTTP
connections.
[snip]
As for the issue at hand - discerning the queued state of a connection -
do you really expect consistent behaviour? I've never seen the
readyState values defined particularly well, at least at a protocol
level, and the object isn't an open standard (it's not even a standard)
so implementations are likely to differ on such issues.
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Michael Winter wrote: [...] I've never seen the readyState values defined particularly well,
Then it is about time you followed the links in my other followup.
at least at a protocol level,
"Protocol level"? The protocol used is HTTP(S).
and the object isn't an open standard (it's not even a standard)
so implementations are likely to differ on such issues.
But not on this. For example, Gecko's nsIXMLHttpRequest interface
is an implementation of Microsoft's IXMLHTTPRequest interface.
PointedEars
Thomas 'PointedEars' Lahn wrote: For HTTP/1.1 clients,not for HTTP/1.0 clients. I believe 1.0 recommended a max of 4 connections. I don't remember.
There is nothing in RFC1945 to support that.
A quick search for http/1.0 "simultaneous connections" shows that it was a
convention more than a rule, but widely followed.
That does not have anything with the readyState, though. The
additional HTTP connection is not opened when the XMLHTTPRequest
object is created
or its open() method is called. It is opened when send() is called
and
a sufficient number of arguments are provided for it.
Not if it's queued behind other connections, it seems.
Not according to the MSDN Library, XULPlanet, my expectations, and
experience. readyState == 4 means the content has been delivered,
3 means that status code and headers have been received, 2 means
that send() was called (and therefore the HTTP request was made,
or "queued"), and 1 means that open() was called.
What reference do you have for these guesses?
What actually happens, according to my experience, is:
readystate 1 (Loading) = the request has been made and content has started
being delivered
readystate 2 (Loaded) = the content has been delivered but not yet parsed
readystate 3 (Interactive) = the content is ready for interaction, ie, it
can be scripted
readystate 4 (Complete) = the content is fully loaded, parsed, etc.
In IE, for example, you can monitor the readyState of many elements, not
just using "ajax" calls. For example,
<html>
<head><title>test</title>
<script type="text/javascript">alert(document.readyState);</script>
</head><body>test</body>
</html>
This will display "interactive" in IE. Meaning, the document object may be
interacted with via script even though it is not yet fully loaded. If you
alert document.readyState onLoad of the body, it will show "complete"
because the content has fully loaded.
In fact, this simple perl script illustrates it well:
#!/usr/local/bin/perl
$|=1;
print "Content-type: text/html\n\n";
print <<"END";
<html><head><title>test</title>
<script type="text/javascript">
alert(document.readyState);
</script>
</head>
<body>
test
END
sleep(5);
print <<"END";
<br>
test2
<script>
alert(document.readyState);
window.onload=function(){alert(document.readyState );}
</script>
</body>
</html>
END
The first alert shows "loading" because the content is not all delivered
(it's waiting on the sleep call). Then it shows "interactive" at the second
alert because the content is fully delivered. Finally it shows "complete"
after the onload event has fired.
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Matt Kruse wrote: Thomas 'PointedEars' Lahn wrote: For HTTP/1.1 clients,not for HTTP/1.0 clients.
I believe 1.0 recommended a max of 4 connections. I don't remember. There is nothing in RFC1945 to support that.
A quick search for http/1.0 "simultaneous connections" shows that it was a
convention more than a rule, but widely followed.
Care to share your findings?
That does not have anything with the readyState, though. The
additional HTTP connection is not opened when the XMLHTTPRequest
object is created or its open() method is called. It is opened
when send() is called and a sufficient number of arguments are
provided for it.
Not if it's queued behind other connections, it seems.
You are not making any sense. If the XMLHTTP request is queued behind other
connections on application level, the other connection must of course be
disconnected before the new connection for the XMLHTTP request is opened.
Understand that we are _not_ dealing with another protocol, only a
different interface to it.
Not according to the MSDN Library, XULPlanet, my expectations, and
^^^^^^^^^^^^^^^^^^^^^^^ experience. readyState == 4 means the content has been delivered,
3 means that status code and headers have been received, 2 means
that send() was called (and therefore the HTTP request was made,
or "queued"), and 1 means that open() was called.
What reference do you have for these guesses?
The references I have repeatedly pointed you to now.
The references you are ignoring continuously in the process.
And my test results you have been ignoring as well.
What actually happens, according to my experience, is:
readystate 1 (Loading) = the request has been made and content has started
being delivered
readystate 2 (Loaded) = the content has been delivered but not yet parsed
readystate 3 (Interactive) = the content is ready for interaction, ie, it
can be scripted
readystate 4 (Complete) = the content is fully loaded, parsed, etc.
This is just plain wrong. Watch your netstat(1) or equivalent network
monitor (TCPView is great on Windows) if you do not believe neither me
nor what is specified by the vendors themselves. (Regarding Gecko-based
UAs, you can even have a look in the source code at Mozilla LXR to see
this confirmed.)
In IE, for example, you can monitor the readyState of many elements, not
just using "ajax" calls.
I thought that we are talking about XMLHTTP requests and the IXMLHTTPRequest
interface (and its implementations in other AOMs) here, so that other host
objects have such an event handler, too, in the IE DOM, would be completely
irrelevant.
PointedEars
Thomas 'PointedEars' Lahn said the following on 3/21/2006 1:40 AM: Matt Kruse wrote:
<snip> In IE, for example, you can monitor the readyState of many elements, not
just using "ajax" calls.
I thought that we are talking about XMLHTTP requests and the IXMLHTTPRequest
interface (and its implementations in other AOMs) here, so that other host
objects have such an event handler, too, in the IE DOM, would be completely
irrelevant.
The different states represented by readyState is very relevant.
You are a real work of art sometimes Thomas. The same tests that he used
to show you what the different states represent can be performed with an
HTTPRequest Object.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Thomas 'PointedEars' Lahn wrote: A quick search for http/1.0 "simultaneous connections" shows that it
was a convention more than a rule, but widely followed. Care to share your findings?
Do the search. See the same findings.
You are not making any sense. If the XMLHTTP request is queued
behind other connections on application level, the other connection
must of course be disconnected before the new connection for the
XMLHTTP request is opened. Understand that we are _not_ dealing with
another protocol, only a different interface to it.
At the JS level, I can open and send as many xmlHttpRequest objects as I
want to in my code.
But at the app/browser level, that doesn't mean they all become active
connections immediately.
Regardless of how it's implemented, the fact is that two "ajax" connections
at a time are opened back to the server and others are queued until one of
the first two finishes. Running my "Queued Requests" example at http://www.ajaxtoolbox.com/request/examples.php clearly shows this. Clicking
all 10 buttons quickly and then running 'netstat' at the command prompt on
windows shows that only two TCP connections to the server are ever open at a
time, even though 10 send() calls have been made.
I'm not going to even argue about the readystate values, since it's just a
diversion from the original question.
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
On Mon, 20 Mar 2006 16:03:31 -0600, "Matt Kruse"
<ne********@mattkruse.com> wrote: readyState 1 means "loading". Which is misleading. Because if the request is
queued, then it hasn't actually started loading yet. I would have expected
these requests to stay in readyState 0 until they actually opened a
connection to the server. ReadyState 2 means loaded, meaning the content has
been delivered. That is certainly not what I want.
I think you should consider the xmlhttp object talking to a local
caching proxy, thinking of it like this makes a lot of things make
sense, and would explain why it's immediately a 1 - I don't believe
there's any way to do what you want though.
I had considered pooling the objects and reusing them. However, my own tests
didn't show much speed improvement, if any. So for now I am not re-using
objects. If that's the only concern, then that's not too bad ;)
There are also quite a few differences in implementations when
re-using, probably not worth it.
Jim.
On Mon, 20 Mar 2006 23:17:53 -0600, "Matt Kruse"
<ne********@mattkruse.com> wrote: What actually happens, according to my experience, is:
readystate 1 (Loading) = the request has been made and content has started
being delivered
readystate 2 (Loaded) = the content has been delivered but not yet parsed
readystate 3 (Interactive) = the content is ready for interaction, ie, it
can be scripted
readystate 4 (Complete) = the content is fully loaded, parsed, etc.
No, these aren't accurate, you can tell simply by putting a sleep in a
server script, you'll see 2 fires long before the full data is
available.
Jim.
Matt Kruse wrote: Thomas 'PointedEars' Lahn wrote: A quick search for http/1.0 "simultaneous connections" shows
that it was a convention more than a rule, but widely followed. Care to share your findings?
Do the search. See the same findings.
You are evading. You are trying to make the point, you are to prove it.
You are not making any sense. If the XMLHTTP request is queued
behind other connections on application level, the other connection
must of course be disconnected before the new connection for the
XMLHTTP request is opened. Understand that we are _not_ dealing with
another protocol, only a different interface to it.
At the JS level, I can open and send as many xmlHttpRequest objects as I
want to in my code.
And you can. (ns)IXMLHTTPRequest::open() does _not_ mean that a HTTP
connection is opened, it is just initialization of the (ns)IXMLHTTPRequest
object. Will you please recognize that?
But at the app/browser level, that doesn't mean they all become active
connections immediately.
Regardless of how it's implemented, the fact is that two "ajax"
connections at a time are opened back to the server and others are queued
until one of the first two finishes.
This was not debated at all. (Will you please read more carefully what
was replied?) However, there are exactly _no_ additional HTTP requests
made, and so _no_ requests originating from (ns)IXMLHTTPRequest can be
ever queued, before you call the (ns)IXMLHTTPRequest::send() method.
Since calling send() is described to change IXMLHTTPRequest::readyState
to 2, and the `readyState' property value is described does not change
to 3 (status header, response headers, and maybe leading parts of the
response body received) or greater (4: response body received completely)
before any response is received for the request, 2 is the `readyState'
value you should be looking for when attempting to detect requests that
are still in a possible request queue at the application level. At
least in IE. (Geckos behave differently: with 2 it is described and
implemented that you already got the headers, so the request was made;
digging out from Mozilla LXR when readyState is set to 2 in the process
exactly is left as an exercise to the reader.)
I'm not going to even argue about the readystate values, since it's
just a diversion from the original question.
It is the whole point of your question. You just diverted from the
readyState values of (ns)IXMLHTTPRequest to the readyState values of
(IE) DOM objects, needlessly.
ISTM you have made up your mind already, and there is no argument strong
enough (not even test results of the actual implementation) to convince you
that you have a misconception. Unless you at least recognize what really
happens (and you have said nothing to deny that so far), this is EOD for
me. I have better ways to waste my time.
Score adjusted
PointedEars
Jim Ley wrote: [...] "Matt Kruse" [...] wrote: readyState 1 means "loading". Which is misleading. Because if the request
is queued, then it hasn't actually started loading yet. I would have
expected these requests to stay in readyState 0 until they actually
opened a connection to the server. ReadyState 2 means loaded, meaning
the content has been delivered. That is certainly not what I want.
I think you should consider the xmlhttp object talking to a local
caching proxy, thinking of it like this makes a lot of things make
sense, and would explain why it's immediately a 1
NO connection is established before send() is called, including a possible
connection to a local caching proxy. That is at least what my tests with
Mozilla/5.0/Linux, Opera 8.52/Linux and Konqueror/3.5 have showed; which
admittedly did not include IE, though.
- I don't believe there's any way to do what you want though.
My tests combined with what MSDN Library has to say about this, indicate
that readyState == 1 is a strong indicator for a queued request. Directly
after send() is called, readyState is still 1, and that does not change
(to 2 or 3) before the connection is established. I had considered pooling the objects and reusing them. However, my own
tests didn't show much speed improvement, if any. So for now I am not
re-using objects. If that's the only concern, then that's not too bad ;)
There are also quite a few differences in implementations when
re-using, probably not worth it.
-v
PointedEars
On Tue, 21 Mar 2006 15:54:23 +0100, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote: Jim Ley wrote: I think you should consider the xmlhttp object talking to a local
caching proxy, thinking of it like this makes a lot of things make
sense, and would explain why it's immediately a 1
NO connection is established before send() is called, including a possible
connection to a local caching proxy.
Who said there was? I suggested you think of it as if there was an
internal as in inside the UA caching proxy, no external test is going
to show this, but like I said, it's a mental model to help you
understand the process, and not what actually happens. - I don't believe there's any way to do what you want though.
My tests combined with what MSDN Library has to say about this, indicate
that readyState == 1 is a strong indicator for a queued request. Directly
after send() is called, readyState is still 1, and that does not change
(to 2 or 3) before the connection is established.
2 doesn't come along until long after a connection is established,
indeed you can not get a 2 until long after even thet status code has
arrived (try a status 100 with IE for example)
Jim.
Jim Ley wrote: [...] Thomas 'PointedEars' Lahn [...] wrote: Jim Ley wrote: I think you should consider the xmlhttp object talking to a local
caching proxy, thinking of it like this makes a lot of things make
sense, and would explain why it's immediately a 1
NO connection is established before send() is called, including a
possible connection to a local caching proxy.
Who said there was?
Matt and you implied that.
I suggested you think of it as if there was an internal as in inside the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
UA caching proxy,
^^^^^^^^^^^^^^^^^
Pardon?
no external test is going to show this, but like I said, it's a mental
model to help you understand the process, and not what actually happens.
Why using a proxy as an argument or a mental model if it cannot even be
involved at that stage?
- I don't believe there's any way to do what you want though.
My tests combined with what MSDN Library has to say about this,
indicate that readyState == 1 is a strong indicator for a queued
request. Directly after send() is called, readyState is still 1,
and that does not change (to 2 or 3) before the connection is
established.
2 doesn't come along until long after a connection is established,
indeed you can not get a 2 until long after even thet status code has
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^ arrived (try a status 100 with IE for example)
^^^^^^^
Pardon?
PointedEars
On Tue, 21 Mar 2006 16:37:38 +0100, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote: Jim Ley wrote: no external test is going to show this, but like I said, it's a mental
model to help you understand the process, and not what actually happens.
Why using a proxy as an argument or a mental model if it cannot even be
involved at that stage?
The proxy is inside the browser, the reason to think of it like that
is because that's how caching makes sense, how requests make sense,
etc. etc. 2 doesn't come along until long after a connection is established,
indeed you can not get a 2 until long after even thet status code has
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^ arrived (try a status 100 with IE for example)
^^^^^^^
Pardon?
Just do what it says, perform a test using XMLHTTPRequest receiving a
properly formatted HTTP status 100 response, and see the state
changes.
Jim.
Thomas 'PointedEars' Lahn said the following on 3/21/2006 9:54 AM: Jim Ley wrote:
<snip> - I don't believe there's any way to do what you want though.
My tests combined with what MSDN Library has to say about this, indicate
that readyState == 1 is a strong indicator for a queued request.
And MSDN is the one that says that the HTTPRequest Object is a native
object in IE7 so just because MSDN says something doesn't make it true -
far from it.
Testing may or may not prove it but "MSDN Says it" doesn't mean a whole lot.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jim Ley wrote: readystate 1 (Loading) = the request has been made and content has
started being delivered
readystate 2 (Loaded) = the content has been delivered but not yet
parsed readystate 3 (Interactive) = the content is ready for
interaction, ie, it can be scripted
readystate 4 (Complete) = the content is fully loaded, parsed, etc.
No, these aren't accurate, you can tell simply by putting a sleep in a
server script, you'll see 2 fires long before the full data is
available.
You are correct, I actually had a faulty test case.
Here is my current server-side script being called:
#!/usr/local/bin/perl
$|=1;
sleep(5);
print "Content-type: text/html\n\n";
sleep(5);
print <<"END";
<html>
<head><title>test</title></head>
<body>
test
END
sleep(5);
print <<"END";
<br>
test2
</body>
</html>
END
As you can see, it sleeps before the full headers are returned, then again
after the headers are done, then again when half the content is returned.
In my test, readystate 1 fires immediately. Readystate 2 and 3 seem to fire
at the same time, after the 2nd sleep, meaning some content has been
delivered (not just the headers, which are complete after the first sleep).
Then readystate 4 fires when the whole document is loaded.
I can't seem to create a test case where there is a delay between 2 and 3
firing. Can you create one?
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Thomas 'PointedEars' Lahn wrote: Do the search. See the same findings. You are evading. You are trying to make the point, you are to prove
it.
There are a number of search results, all making the same point. Listing the
url's that you can view for yourself hardly seems worthwhile.
And you can. (ns)IXMLHTTPRequest::open() does _not_ mean that a HTTP
connection is opened, it is just initialization of the
(ns)IXMLHTTPRequest object. Will you please recognize that?
Of course. That's obvious. I've never said differently.
This was not debated at all. (Will you please read more carefully
what was replied?) However, there are exactly _no_ additional HTTP
requests made, and so _no_ requests originating from
(ns)IXMLHTTPRequest can be ever queued, before you call the
(ns)IXMLHTTPRequest::send() method.
Agreed from the beginning. But calling send() on 5 requests at a time, for
example, is what I'm talking about.
Since calling send() is described to change
IXMLHTTPRequest::readyState
to 2
Where is this described? Clearly it does not.
2 is the
`readyState' value you should be looking for when attempting to
detect requests that are still in a possible request queue at the
application level. At least in IE.
False conclusion. Just test it!
Score adjusted
+1?
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Jim Ley wrote: [...] Thomas 'PointedEars' Lahn [...] wrote: Jim Ley wrote: no external test is going to show this, but like I said, it's a mental
model to help you understand the process, and not what actually happens.
Why using a proxy as an argument or a mental model if it cannot even be
involved at that stage?
The proxy is inside the browser, the reason to think of it like that
is because that's how caching makes sense, how requests make sense,
etc. etc.
There is no proxy inside any HTTP client. 2 doesn't come along until long after a connection is established,
indeed you can not get a 2 until long after even thet status code has
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^ arrived (try a status 100 with IE for example)
^^^^^^^
Pardon?
Just do what it says, perform a test using XMLHTTPRequest receiving a
properly formatted HTTP status 100 response, and see the state
changes.
I do not understand what it says.
PointedEars
Jim Ley wrote: [...] Thomas 'PointedEars' Lahn [...] wrote: Jim Ley wrote: 2 doesn't come along until long after a connection is established,
indeed you can not get a 2 until long after even thet status code has
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^ arrived (try a status 100 with IE for example)
^^^^^^^
Pardon?
Just do what it says, perform a test using XMLHTTPRequest receiving a
properly formatted HTTP status 100 response, and see the state
changes.
I do not understand what it says.
PointedEars
On 21/03/2006 01:28, Thomas 'PointedEars' Lahn wrote: Michael Winter wrote:
[snip] at least at a protocol level,
"Protocol level"? [...]
It seems that I wasn't thinking properly when I wrote that. :-/ Never
mind... and the object isn't an open standard (it's not even a standard)
so implementations are likely to differ on such issues.
But not on this. For example, Gecko's nsIXMLHttpRequest interface
is an implementation of Microsoft's IXMLHTTPRequest interface.
Yet the documentation that you link to in your first follow-up[1]
describes very different meanings for the LOADED and INTERACTIVE states.
The documentation for Microsoft's XML SDK 3.0 is in-line with the
description for the Gecko implementation.
Mike
[1] <41****************@PointedEars.de>
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Michael Winter wrote: On 21/03/2006 01:28, Thomas 'PointedEars' Lahn wrote: Michael Winter wrote: and the object isn't an open standard (it's not even a standard)
so implementations are likely to differ on such issues.
But not on this. For example, Gecko's nsIXMLHttpRequest interface
is an implementation of Microsoft's IXMLHTTPRequest interface.
Yet the documentation that you link to in your first follow-up[1]
describes very different meanings for the LOADED and INTERACTIVE states.
True, however it is clear (and tested) that readyState will not be 2
before the connection is opened in either implementation. So that
can serve as an indicator for possible queueing (what a word! :)) of
requests.
The documentation for Microsoft's XML SDK 3.0 is in-line with the
description for the Gecko implementation.
What do you mean by that?
PointedEars
On 21/03/2006 22:30, Thomas 'PointedEars' Lahn wrote: Michael Winter wrote:
[snip] The documentation for Microsoft's XML SDK 3.0 is in-line with the
description for the Gecko implementation.
What do you mean by that?
The description of the various states is almost identical to those
featured on the xulplanet.com site, at least according to the local MSDN
documentation I have here. However, the on-line documentation seems to
be rather muddled showing both, with the new XMLHTTP object for IE7[1]
exhibiting the differences previously seen.
Mike
[1]
<http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/readystate_3.asp>
--
Michael Winter
Prefix subject with [News] before replying by e-mail. This discussion thread is closed Replies have been disabled for this discussion. Similar topics
20 posts
views
Thread by chris.schwalm |
last post: by
|
reply
views
Thread by WGM |
last post: by
|
6 posts
views
Thread by Nathan |
last post: by
|
6 posts
views
Thread by Jack |
last post: by
|
1 post
views
Thread by geevaa |
last post: by
| | |
167 posts
views
Thread by darren |
last post: by
|
2 posts
views
Thread by Michael Nemtsev [MVP] |
last post: by
| | | | | | | | | | | | | | | | | | | |
