Hmm, I wouldn't think so because that would be tunneling.
The difference between message separation with MIME multi-parts and HTTP
messages is that multi-parts are separated by boundaries and HTTP messages
are generally encapsulated by Content-Length (other ways too). The
difference in
Pipelining Control
HTTP Pipelining is when more than one outstanding request is sent over a
single TCP connection, and it was introduced in HTTP 1.1. This
proposal defines that XHR objects should be able to control whether or not
they are pipelined. A pipeline property would be added to the
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
Multipart Support
Multipart support specifies that when an XHR request is made with multipart
enabled, the XHR response should be parsed as a multipart message, where
each part triggers the XHR response sequence. Multipart handling is enabled
by setting the multipart property on the XHR object
: Jonas Sicking [EMAIL PROTECTED]
To: Kris Zyp [EMAIL PROTECTED]
Cc: public-webapi@w3.org; Mark Baker [EMAIL PROTECTED]
Sent: Tuesday, February 19, 2008 11:26 AM
Subject: Re: Pipelining Control Proposal
I would be very worried about implementing this feature in a browser since
it runs a very big
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.
state of these issues. I will do my best to find whatever information I
can.
I appreciate that, I will try to research it as well. Five years is a long
time in on the web, a lot could have changed.
Some evidence I have turned up with a little research:
Opera supports pipelining by default.
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
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
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
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: public-webapi@w3.org
Sent: Thursday, March 06, 2008 6:16 AM
Subject: Re: Extra Connection Support Proposal
However, there are web apps in existence (e.g., Gmail)
that set the connection: close header to inform the
user-agent that the HTTP transaction is going to take
a long time. (This is also informative for the
server.) This allows a user-agent to not count this
connection against the RFC 2616
If the problem we are trying to solve is preventing potentially long-
lived requests from blowing out the connection limit I think it would be
better to either:
1) Add an explicit XHR property that indicates this request may be
long-lived - this would not only bypass the connection limit
As far as I can tell, Firefox is the only browser that regards
connection: close as an indication that the connection should not be
counted against the connection limit
What gives you that idea? I'm not actually sure since I don't know the
inner workings of the network code, but I have
for UAs is best approach, and that it should be a number-based advice,
not a boolean, so that it could be used more effectively and flexibly in
heuristic algorithms for making informed pipelining decisions.
Can you be more specific in what you mean about number-based advice?
(Apologies
As a browser implementor, I don't think I would find this more useful
than a boolean property indicating a connection is likely to be long-
lived. I can't imagine doing anything more complicated than picking a
threshold value to decide whether to count a request towards the
connection limit
How does this compare to the Cross-Site Extensions for XMLHttpRequest
standard
that is being developed by Web API and Web App Formats (and
as implemented in Firefox betas)?
The major ones, IMO:
1. XDomainRequest uses a different constructor/API to make requests
(XDomainRequest instead of
If XDR only supports GET and POST, it encourages sites to use POST to
implement delete functionality and abuse the HTTP protocol because that
is the only way they can get the functionality they desire to work.
Basically, you’re boycotting REST in favour of SOAP.
I completely agree, it shouldn't
From web developer's perspective, the idea of having a completely divergent
API and technique for doing cross-site requests between browsers does not
seem beneficial. As much as possible I would hope that MS and CS-XHR can
converge. It seems like there are a number of differences that can be
I don't know whether most modern devs are using JSON,
Yeah, I really don't have any data to back that up, I shouldn't make such
claims :). But I think it is safe to say that many devs use it.
More generically, I don't think that new cross-origin APIs that
just return a string (but are
We still do not have anyway to advice user agents of long-lived responses in
order to avoid the problem of indefinitely queued pipelined
requests/responses. With both pipelining and long-lived responses becoming
more common, this seems to be an envitable problem. It doesn't seem
acceptable
OK, that's fine, I just didn't want it to be ignored indefinitely.
Thanks,
Kris
- Original Message -
From: Maciej Stachowiak [EMAIL PROTECTED]
To: Kris Zyp [EMAIL PROTECTED]
Cc: Web API WG (public) public-webapi@w3.org; Anne van Kesteren
[EMAIL PROTECTED]
Sent: Wednesday, April 16
22 matches
Mail list logo
