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.
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.
Re: Extra Connection Support Proposal
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 problem yeah. Though if it's simply multiple images the new page will likely get squeezed in between two of the image downloads. And there is an important distinction between images being downloaded that consume connections and a long-lived response that consume a connection. With normal responses, two connection usually provides a means for relatively continuous utilization of resources. Most of the time two connections provide enough requests that the usually the server is processing a request, or a response is downloading. Either way, something is being done, and it is quite reasonable for further requests to be queued, since the server/connection is working to finish the response as fast as possible within it's capability. On the otherhand, when a long-lived response is paused indefinitely until a the server has a message to be sent, there is nothing being done. Nothing is being downloaded, and the server isn't working on anything, and requests can be queued indefinitely even though nothing is happening. Yup, it seems like people agree with this. It's just the proposal to put it as a feature on XHR that seems to be disliked by a few people, me included. 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... / Jonas
Re: Extra Connection Support Proposal
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 more so than XHR to me) and is much more solidified and it seems unlikely that there would a be solution down that path. And I don't see how it is any more right for this to be done in HTTP, The user agent needs to be informed by something, and I don't see a clear distinction in why it is superior to be informed by the HTTP response rather than API/author since this doesn't really affect the actual HTTP communication protocol, but when a user agent chooses to use an (additional) HTTP communication channel. I am concerned that if all parties continually come up with really good reasons to keep deferring this to someone else, the user with hanging requests still lose. I am going to send out another proposal that will hopefully be more palatable/feasible. Thanks, Kris
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 no sense that only XMLHttpRequest would benefit from this. That doesn't help video, lots of external style sheets, images, etc. We need something helps all those APIs. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Extra Connection Support Proposal
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 waiting for a connection to become available. This is a serious usability issue. Is there something that I need to do to improve my proposal, so can effectively tackle this issue, and provide a means for authors to inform the user agents when a response is long-lived? Thanks, Kris
Re: Extra Connection Support Proposal
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 mentioned, if you click a link on a page with downloads happening, the browser can abort responses for images that are being downloaded, which immediately frees up connections. On the otherhand, if a couple connections are indefinitely open, and you open another tab that needs a connection, the browsers hangs... indefinitely. Kris
Re: Extra Connection Support Proposal
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 another tab), the browser is stuck and essentially hangs waiting for a connection to become available. This is a serious usability issue. Is there something that I need to do to improve my proposal, so can effectively tackle this issue, and provide a means for authors to inform the user agents when a response is long-lived? The problem has always existed, though. For example, if you're downloading a page with very large images on it (or perhaps multipart/x-mixed-replace feeds from a webcam) and whilst the browser is tied up downloading them all, 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 if it's simply multiple images the new page will likely get squeezed in between two of the image downloads. / Jonas
Re: Extra Connection Support Proposal
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. That is if the user agent adheres to the two-connection limit as recommended by RFC 2616 section 8.1.4, it SHOULD allow two connections not counting this XHR object's connection. If the user agent has other or additional connection limits, this connection should not be counted in the accounting for these connection limits. 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. - Maciej Only one XHR object should be allowed to gain extra connection status per document per server. Each document in the browser may be permitted one extra connection per server. Within a document if an XHR object has an extra connection status for domain1.com, no other XHR objects may have extra connection status for that server until the first XHR object has terminated it's connection. However, another XHR object may have extra connection status to domain2.com. Each document in the browser should have it's own set of extra connections for XHR objects. This limitation is intended to prevent a vector of denial of service attacks. To gain extra connection status, the extraConnection property on the XHR object can be set to true. When it is set to true, if the XHR object is allowed to gain extra connection status (no other XHR objects currently have extra connection status in this document for the specified target server), the XHR object will be given extra connection status and subsequent access to the property will return true. If the XHR object is not allowed to gain extra connection status, subsequent access to the property should return false. The following is an example of valid usage: var xhr = new XMLHttpRequest(); xhr.open(GET,/resource,true); xhr.extraConnection = true; var succesful = xhr.extraConnection; Setting the extraConnection property should throw an exception if it is called before a URL is provided to the XHR object (through the open method or the constructor). The extra connection status remains in effect until the connection is closed (by network error on normal termination), at which point the property should return false. Since the extraConnection property usually indicates that the response will be a long-lived streaming response, user agents SHOULD NOT pipeline requests on this connection unless the author explicitly specifies such pipelines using pipelining control (see the Pipelining Control Proposal).
Re: Extra Connection Support Proposal
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 don't have a big problem with this being defined by headers, that seems reasonable. It is worth noting that doesn't achieve quite the same effect as doing it in XHR since there is time elapsed between the time the request is made and the response headers are received. If two connections are currently servicing responses, and third connection wishes to declare itself as an extra connection, from the client side this could be delivered immediately, but with header based permission, it would have to wait it's turn. That being said, I don't think these are terrible issues, and a fixing it at the HTTP level is fine with me. Kris
Re: Extra Connection Support Proposal
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 specific connection should not count towards the limit. I don't have a big problem with this being defined by headers, that seems reasonable. It is worth noting that doesn't achieve quite the same effect as doing it in XHR since there is time elapsed between the time the request is made and the response headers are received. If two connections are currently servicing responses, and third connection wishes to declare itself as an extra connection, from the client side this could be delivered immediately, but with header based permission, it would have to wait it's turn. That being said, I don't think these are terrible issues, and a fixing it at the HTTP level is fine with me. Kris XHR is an application-level protocol. I am not in favour of permitting XHR clients control over connection-level properties. The HTTP code should be responsible for pipelining and connection management - it is absolutely no concern of the application layer how it achieves its objective, which is simply the transmission of an HTTP request message and reception of an HTTP response message. 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. My HTTP code contains adaptive behaviour to deliver the optimum results based on prior history with the servers and proxies with which it is communicating. I'm sure other HTTP clients do similar things. A major part of this is working around known bugs in servers (like the aforementioned failures to support pipelining correctly) and a much lesser part (because the capabilities of conditionally using features are built into HTTP already) taking advantage of features, where possible. My code will tend to assume the worst, until it gets evidence that a given feature works. I do not want to permit the application layer to override my decision not to use pipelining, persistent connections, HTTP/1.1 etc. and cause a breakage by doing so. IMHO, allowing application layers control over low-level communications leads to inoperability, surprising behavioural differences in different environments, and makes proper testing of the application as a whole pretty difficult. -- Stewart Brodie
Re: Extra Connection Support Proposal
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 the core systems have the final say seems appropriate. But without these hints a number of important capabilites of emerging web technologies are being severely hampered. XHR already has a lot of relatively low level capabilities including access to and modification of headers (which can be overriden by the underlying subsystems). At least hinting at expectations of long-lived responses and optimum pipeline orderings does not seem out of line with what XHR is. Headers are not a transport detail. Together with the entity body and the HTTP method they form the request. Pipelining on the other hand is something totally different. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
