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.
Thanks for the heads up, Mark, I will be watching the activity there, that
would be great if the problem can be dealt with in that group.
However, the issues of responses being indefinitely queued in pipelining
situations and unbounded memory growth on continuous streaming responses are
still
Doug et All:
Just wanted to check if we are still meeting at the same time next
week. The US will switch
time to Day Light Savings Time this weekend (clocks forward one
hour).Our friends
in Europe/Canada may be off by one hour.
Thanks,
Carmelo Montanez
On Mar 6, 2008, at 7:09 AM, Kris Zyp wrote:
Thanks for the heads up, Mark, I will be watching the activity
there, that would be great if the problem can be dealt with in that
group.
However, the issues of responses being indefinitely queued in
pipelining situations and unbounded memory
Hi, I'm writing about what appears to be an error in
the XHR TR.
In section 2 of http://www.w3.org/TR/XMLHttpRequest/,
it says that setRequestHeader should reject the
connection header.
However, there are web apps in existence (e.g., Gmail)
that set the connection: close header to inform the
Hello,
I work on Google Gears team. If you're not familiar with what Gears
is, you can learn more here: http://code.google.com/apis/gears.
We've been working on an API that will allow an application to obtain
(with permission) the user's current location. I posted this to the
WhatWG mailing
* Morgan L wrote:
In section 2 of http://www.w3.org/TR/XMLHttpRequest/,
it says that setRequestHeader should reject the
connection header.
The purpose of these restrictions is to remind implementers that the
user agent has to control certain headers for protocol integrity or
other reasons, in
