Extra Connection Support
The XMLHttpRequest should define a property called "extraConnection". When
extraConnection is set to true, it indicates that this XHR object's
connection SHOULD NOT be counted against the user agent's connection limit.
That is if the user agent adheres to the two-connec
On Feb 19, 2008, at 7:55 AM, Kris Zyp wrote:
Extra Connection Support
The XMLHttpRequest should define a property called
"extraConnection". When
extraConnection is set to true, it indicates that this XHR object's
connection SHOULD NOT be counted against the user agent's connection
limit.
As with pipelining, I think this would be better handled at the HTTP
level than the XHR API level. We could define response headers for a
server to indicate that it allows more than two connections per client,
or alternately that a specific connection should not count towards the
limit.
I
"Kris Zyp" <[EMAIL PROTECTED]> wrote:
>
> > As with pipelining, I think this would be better handled at the HTTP
> > level than the XHR API level. We could define response headers for a
> > server to indicate that it allows more than two connections per client,
> > or alternately that a spec
If the application layer wishes to provide hints that particular features
should be avoided, then that would be fine - provided that the HTTP
implementation is permitted to ignore the hint. The same goes for
cacheing
- it needs to be hints from the application, not control.
I don't mind if t
On Tue, 19 Feb 2008 20:47:50 +0100, Kris Zyp <[EMAIL PROTECTED]> wrote:
- it needs to be hints from the application, not control.
I don't mind if the wording is such that all the API level properties
are treated as hints/suggestions for the underlying HTTP subsystems,
that is fine. Letting t
"Anne van Kesteren" <[EMAIL PROTECTED]> wrote:
> On Tue, 19 Feb 2008 20:47:50 +0100, Kris Zyp <[EMAIL PROTECTED]> wrote:
> > - it needs to be hints from the application, not control.
> > I don't mind if the wording is such that all the API level properties
> > are treated as hints/suggestions f
"Kris Zyp" <[EMAIL PROTECTED]> wrote:
> We are still faced with the fundamental problem that if a browser that
> observes the two connection limit and two long-lived connections are
> currently open and the user does something that triggers another request
> (such as opening another tab), the bro
The problem has always existed, though.
The problem has always existed, but having long-lived responses for the
purpose of the receiving messages from the server massively exacerbates the
problem. Most responses are intended to be as short-lived as possible. Also,
in the scenario you mentione
Stewart Brodie wrote:
"Kris Zyp" <[EMAIL PROTECTED]> wrote:
We are still faced with the fundamental problem that if a browser that
observes the two connection limit and two long-lived connections are
currently open and the user does something that triggers another request
(such as opening anot
We are still faced with the fundamental problem that if a browser that
observes the two connection limit and two long-lived connections are
currently open and the user does something that triggers another request
(such as opening another tab), the browser is stuck and essentially hangs
waitin
you click on a link, does the link get followed? That is the same sort
of
scenario, isn't it?
At least firefox will abort any existing downloads for the current page
when the user clicks a link. But if you're downloading these images in
another tab you might have this problem yeah. Though
Kris Zyp wrote:
you click on a link, does the link get followed? That is the same
sort of
scenario, isn't it?
At least firefox will abort any existing downloads for the current
page when the user clicks a link. But if you're downloading these
images in another tab you might have this probl
Doing this on an HTTP level seems like the right solution to me. Though
i'm not sure what working group would then be appropriate for
standardizing it...
I don't mind trying this avenue, I just fear that this is even more likely
to be a dead-end. HTTP is already very complicated (it would seem
On Wed, 27 Feb 2008 23:48:47 +0100, Kris Zyp <[EMAIL PROTECTED]> wrote:
I am going to send out another proposal that will hopefully be more
palatable/feasible.
I don't want this in XMLHttpRequest. It makes no sense that only
XMLHttpRequest would benefit from this. That doesn't help , lots o
; Web API WG (public)
Subject: Re: Extra Connection Support Proposal
On Wed, 27 Feb 2008 23:48:47 +0100, Kris Zyp <[EMAIL PROTECTED]> wrote:
> I am going to send out another proposal that will hopefully be more
> palatable/feasible.
I don't want this in XMLHttpRequest. It makes n
FYI, you might be interested in this recent discussion in the HTTP WG,
which could make this proposal unnecessary;
http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0423.html
Mark.
present, and I don't think there is anything the HTTP WG can do about
that.
Thanks,
Kris
- Original Message -
From: "Mark Baker" <[EMAIL PROTECTED]>
To: "Kris Zyp" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, March 06, 2008 6:16 AM
Subject: Re: Extra Co
OTECTED]>
To: "Kris Zyp" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, March 06, 2008 6:16 AM
Subject: Re: Extra Connection Support Proposal
FYI, you might be interested in this recent discussion in the HTTP
WG,
which could make this proposal unnecessary;
http://lists.w3.org/Archive
19 matches
Mail list logo
