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/Archives/Public/ietf-http-wg/2008JanMar/0423.html Mark.
Re: Extra Connection Support Proposal
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 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 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.
Time for Next Week
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
Re: Extra Connection Support Proposal
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 growth on continuous streaming responses are still present, and I don't think there is anything the HTTP WG can do about that. I think a hint that a request is expected to be long-term persistent would be useful in any case, to let the user agent know that it shouldn't pipeline other requests on the same connection. Perhaps this can be a simple boolean, if http itself relaxes connection limits and so removes the need for more complex functionality along these lines. - Maciej 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 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.
XHR setRequestHeader(connection, close) is bogusly rejected
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 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 recommended maximum of 2 persistent connections per host. So, it seems to me that the arguments setRequestHeader(connection, close) should be allowed. More details in this WebKit bug: http://bugs.webkit.org/show_bug.cgi?id=17682 It looks like recent versions of WebKit and Gecko block the connection request header per this TR. However, Firefox 2 does not. --morgan Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Geolocation API proposal
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 list, but it was suggested that this might be a more appropriate place. Anyway, here's our current design: http://code.google.com/p/google-gears/wiki/LocationAPI We think there's a lot of potential for interesting applications with a API like this. Some examples would be recommendations for nearby restaurants, turn by turn directions, or city walking tours. Are there any other vendors interested in implementing something like this? If so, we'd like to work together to come up with a standard. Otherwise, I'll just put this out there for comment for the time being. We'd appreciate any feedback on the design, one way or the other. Thanks, -- Aaron Boodman
Re: XHR setRequestHeader(connection, close) is bogusly rejected
* 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 other words, implementations should not blindy pass to the server whatever value a script might have set there. It should be perfectly permissable if the implementation instead of ignoring the attempt at setting some value takes the attempt under advisement when making its own decisions what to set the header to, in other words, the browser might well list close among the tokens after a script tried to set the header. I agree the current text does not convery this very well, do you have a suggestion how to editorially improve it? We can't simply allow this particular case as simply sending Connection: close can be wrong in many cases (see e.g. RFC 2616, section 13.5.1). -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
