Re: XHR setRequestHeader(connection, close) is bogusly rejected
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 if you explained this in an earlier message, I tried skimming them and did not find a description). I couldn't find my previous message in the archives, so I included below again (sorry about posting it again). Basically I was suggesting that a property (called durability) could take a number (rather than a boolean), that would represent advice about how long the author expected the response to take. The user agent could utilize this advice in any way it sees fit. A number provides more information (a greater range of values) than a boolean, and it could effectively be used as weighting in user agent heuristics. The advice could be used by user agents to determine if the connection should be counted against the connection limit (if it is larger than a threshold), and it could used as advice for pipelining. The user agent is not required to respond in any certain way, but this is author provided advice, that the user agent may use in any way it desires. The advantage of a number may be more clearly seen in a pipeline ordering example. Suppose I issue 4 requests, and I expect request A to take a few milliseconds, request B to take a half a second, request C to take a couple seconds, and request D could last indefinitely. I could set different durability values for each XHR request, and then the user agent could potentially use these values (possibly in combination with other information, like connection speed, proxy information, and so forth) to determine the order of pipelining: xhrA.durability = 0.01; xhrB.durability = 0.5; xhrC.durability = 2; xhrD.durability = 100; In this situation, a browser may decide to send A and B on different connections, and send C as pipelined by request A. It may also choose to send D on completely separate connection and not count that against the connection limit. However, the advice does not require the user agent to take any specific action, the browser can weigh the advice in combination with other factors, depending on the situation. Anyway, here is the more detailed proposal I had sent out, I apologize if you have already received it/read it (it had a subject Re: Pipelining Control Proposal): I wanted to propose another way to deal with the usability issues involved with pipelining in combination with long-lived responses for the purposes of server initiated messages. This is not an opposition to HTTP improvements for declaring extra connection limits. I hope that happens for the broader benefit that it provides and that HTTP improvements can solve the two- connection limit probem, however as I articulate in the reasons at the bottom, HTTP improvements are simply not sufficient for avoiding pipeling issues, and a simple mechanism for providing connection advise is critical as well. I believe this is a very minimalistic approach only adds a trivial amount of complexity to the XMLHttpRequest spec and has almost zero required implementation burden. The addition property defined here can be used by user agents to deal with the problem of responses becoming indefinitely queued due to being pipelined on a connection where a previous response is never finished or simply takes a long time. I propose that we have define a property called durability to the XMLHttpRequest object, that can be assigned a positive number (x = 0) by authors that want to advise the user agent on how long they expect the given request to last. A low value indicates that the request is expected to be very quick and a high value indicates that the request is expected to take longer. The durability property should default to 1, and so a value of 1 indicated a request with an average length of time. The durability property can set and modified at any time before, during, or after a request. A user agent is not required to behave in any particular way in response to the durability property, it is simply a standard way for authors to provide information about how long the response will probably take so that user agents can utilize this information in making informed optimization decisions, and provide a means for intelligently avoiding indefinitely queued requests/responses. There are no requirements for how the user agent responds to this property, but it is recommended that user agents use this information to help optimize pipelining (and potentially connection limiting). The lower the durability value, the faster the request is likely to receive a response, and therefore the corresponding connection is a better candidate for pipelining if that is enabled in the user agent. The higher the durability value, the slower the request is likely to receive a response, and therefore a
Re: XHR setRequestHeader(connection, close) is bogusly rejected
On Mar 11, 2008, at 7:00 AM, Kris Zyp wrote: 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 if you explained this in an earlier message, I tried skimming them and did not find a description). I couldn't find my previous message in the archives, so I included below again (sorry about posting it again). Basically I was suggesting that a property (called durability) could take a number (rather than a boolean), that would represent advice about how long the author expected the response to take. The user agent could utilize this advice in any way it sees fit. A number provides more information (a greater range of values) than a boolean, and it could effectively be used as weighting in user agent heuristics. The advice could be used by user agents to determine if the connection should be counted against the connection limit (if it is larger than a threshold), and it could used as advice for pipelining. The user agent is not required to respond in any certain way, but this is author provided advice, that the user agent may use in any way it desires. The advantage of a number may be more clearly seen in a pipeline ordering example. Suppose I issue 4 requests, and I expect request A to take a few milliseconds, request B to take a half a second, request C to take a couple seconds, and request D could last indefinitely. I could set different durability values for each XHR request, and then the user agent could potentially use these values (possibly in combination with other information, like connection speed, proxy information, and so forth) to determine the order of pipelining: xhrA.durability = 0.01; xhrB.durability = 0.5; xhrC.durability = 2; xhrD.durability = 100; In this situation, a browser may decide to send A and B on different connections, and send C as pipelined by request A. It may also choose to send D on completely separate connection and not count that against the connection limit. However, the advice does not require the user agent to take any specific action, the browser can weigh the advice in combination with other factors, depending on the situation. Anyway, here is the more detailed proposal I had sent out, I apologize if you have already received it/read it (it had a subject Re: Pipelining Control Proposal): 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 and whether to consider pipelining requests on its connection. If all implementors did this, we'd likely end up with somewhat different threshold values, which would be unfortunate. Also, I'm skeptical that authors can estimate request latency with anything near that kind of precision. Thus, it is likely to be an unreliable source of information, meaning that the details of the value couldn't be trusted anyway, and even a high-low threshold might be unreliable. But most authors know if their XHR connection is intended to be used persistently, so the one bit of info would be more trustworthy. Are there any implementors who would find an estimate of the request latency more useful than a boolean likely to be persistent indicator? Regards, Maciej
Re: XHR setRequestHeader(connection, close) is bogusly rejected
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 and whether to consider pipelining requests on its connection. If all implementors did this, we'd likely end up with somewhat different threshold values, which would be unfortunate. We could certainly agree upon and define the threshold values, that is trivial. However, would you want the threshold for connection limit counting and pipelining to be the same (as a boolean would effectively be)? I would think that are some responses that may take a long enough to avoid pipelining, but still count in against the connection limit. More importantly, pipelining is not simply a yes or no question, it is a question of which connection to pipeline on. A faster response is attained by pipelining on the connection that will be able handle the request soonest, and therefore pipelining becomes a comparison calculation. If browsers have numeric values for response time estimates, they can make appropriate comparisons and do optimal pipelining. Perhaps the next iteration of browsers would only be based on thresholds, but numeric values allow great transfer of information, which could be used for more creative optimizations like pipelining comparisons and perhaps optimizations that we haven't even thought of yet. Just because we haven't foreseen all the possible optimizations, doesn't mean we shouldn't leave the door open for such optimizations. By allowing numeric values, authors can begin providing advice, and browsers can use it at their convenience. Also, as I had mentioned in the proposal, there are situations where authors actually want to pipeline requests behind long-lived responses, so they are intentially not responded to. Once again, boolean values don't provide an adequate mechanism for communicated this desire. Also, I'm skeptical that authors can estimate request latency with anything near that kind of precision. Thus, it is likely to be an unreliable source of information, meaning that the details of the value couldn't be trusted anyway, and even a high-low threshold might be unreliable. But most authors know if their XHR connection is intended to be used persistently, so the one bit of info would be more trustworthy. Sure, it is impossible to create perfectly accurate estimates, and it is in fact an estimate and should be treated that way, but it seems very presumptious to assume that authors can't provide meaningful data. If authors don't know, that can simply not set this property or use a very high value to indicate a long-lived response. If they provide errant values, that is their problem, but I don't think we should understimate the potential of what authors can understand and do. Thanks, Kris
Re: XHR setRequestHeader(connection, close) is bogusly rejected
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. 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, and this behavior does _not_ follow the HTTP recommendation regarding connections. Section 8.1.4 states that: Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. (All browsers use persistent connections, so all browsers are subject to the recommendation stated below) A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. There is no mention of only maintaining two persistent connections, all connections (persistent or otherwise) are supposed to be counted against the connection limit. In addition, there is no reason why long-lived responses (those that shouldn't be counted against the connection limit) should have to have their TCP connection closed after the response is fully received. Therefore, I don't see Connection: close as an appropriate means for advising that connections should not be counted against connection limits. Kris
Re: XHR setRequestHeader(connection, close) is bogusly rejected
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 but would also indicate to the UA that it should not pipeline other requests on the same connection, if it supports pipelining. 2) Never count XHR-initiated http requests towards the per-server connection limit. not seem necessary for the goal of bypassing the connection limit on the UA side. And it seems that an explicit XHR property for this would be more clear. I agree, I think #1 is the way to go. I don't like #2, because connection limits really are valuable for minimizing server load, and even can help prevent DOS attacks. As I just mentioned in the other email, Connection: close is not an appropriate form of advice, IMO. I think that an explicit property that provides advice 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. Kris
Re: XHR setRequestHeader(connection, close) is bogusly rejected
Kris Zyp wrote: 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. 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 never heard of such behavior. And in any case Firefox 3 does not even let you set the Connection header using XHR. / Jonas
Re: XHR setRequestHeader(connection, close) is bogusly rejected
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 never heard of such behavior. I have never heard of such behavior either until this thread. I just tried it out against Safari 3, IE8, Opera 9, and FF2. Only FF2 seemed to be affected by Connection: close. FF2 seems to let me open an indefinite number of connections to a server if use Connection: close, but only two connections are allowed if don't use it. I was surprised as well. FF3 is not affected by Connection: close, only FF2. Kris
Re: XHR setRequestHeader(connection, close) is bogusly rejected
On Mar 10, 2008, at 4:37 PM, Jonas Sicking wrote: Kris Zyp wrote: 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. 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 never heard of such behavior. A commenter on this WebKit bug said so: http://bugs.webkit.org/show_bug.cgi?id=17682 . But further testing does not seem to bear out this claim. Regards, Maciej
Re: XHR setRequestHeader(connection, close) is bogusly rejected
On Mar 10, 2008, at 7:34 AM, Kris Zyp wrote: 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 but would also indicate to the UA that it should not pipeline other requests on the same connection, if it supports pipelining. 2) Never count XHR-initiated http requests towards the per-server connection limit. not seem necessary for the goal of bypassing the connection limit on the UA side. And it seems that an explicit XHR property for this would be more clear. I agree, I think #1 is the way to go. I don't like #2, because connection limits really are valuable for minimizing server load, and even can help prevent DOS attacks. As I just mentioned in the other email, Connection: close is not an appropriate form of advice, IMO. I think that an explicit property that provides advice 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 if you explained this in an earlier message, I tried skimming them and did not find a description). Regards, Maciej
Re: XHR setRequestHeader(connection, close) is bogusly rejected
--- Maciej Stachowiak [EMAIL PROTECTED] wrote: On Mar 7, 2008, at 3:02 PM, Morgan L wrote: Ah, that make sense to me. I think the current text has caused major browser engines to mistakenly stop supporting connection: close. It is easy to blindly implement whatever the standards say :-) I think it would help if a caveat were added along the lines of what you have written here. I think the connection: close example should be used to demonstrate why it might be wise for a user-agent to customize what request headers it rejects. I'm not sure that section 13.5.2 implies that connection: close can be wrong. It is true that an XHR users cannot assume that the origin server will see the connection: close header, but it is still always the case that the UA would see it. And, in the example that I provided, the goal is to tell the UA that it does not need to count this request against the max-persistent-connections-per-host limit. At least, I can't see how allowing XHR users to specify connection: close can be regarded as harmful. Thoughts? 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 but would also indicate to the UA that it should not pipeline other requests on the same connection, if it supports pipelining. 2) Never count XHR-initiated http requests towards the per-server connection limit. Given that IE has increased their per-server connection limit to 6, and since the HTTP working group is considering dropping the connection limit as a formal spec requirement, I would probably advise #2 for WebKit and have commented to that effect in the bug you cited. From the spec point of view, I think #1 makes more sense since it may be inappropriate to require #2 (thoughts from other implementors welcome). Requiring UAs to recognize Connection: close as a hint that the connection may be long-lived and should not count towards the limit is also possible as a variant of option 1. But I am not sure they should be required to also pass the header to the origin server. This does not seem necessary for the goal of bypassing the connection limit on the UA side. And it seems that an explicit XHR property for this would be more clear. I agree that an explicit API would be more clear, but my point in bringing this up was that there is an API already supported by the majority browsers that has been broken by the TR. So, it seems like it would be good for the TR to reflect reality first. If an extra API makes sense, that's fine, but that would seem to be something that should be additive. Jonas: I agree that XHR users should not be able to pass connection: keep-alive. You should see that I've been arguing for connection only be allowed with the close value. --morgan Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: XHR setRequestHeader(connection, close) is bogusly rejected
--- Bjoern Hoehrmann [EMAIL PROTECTED] wrote: * 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). Ah, that make sense to me. I think the current text has caused major browser engines to mistakenly stop supporting connection: close. It is easy to blindly implement whatever the standards say :-) I think it would help if a caveat were added along the lines of what you have written here. I think the connection: close example should be used to demonstrate why it might be wise for a user-agent to customize what request headers it rejects. I'm not sure that section 13.5.2 implies that connection: close can be wrong. It is true that an XHR users cannot assume that the origin server will see the connection: close header, but it is still always the case that the UA would see it. And, in the example that I provided, the goal is to tell the UA that it does not need to count this request against the max-persistent-connections-per-host limit.At least, I can't see how allowing XHR users to specify connection: close can be regarded as harmful. Thoughts? --morgan Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: XHR setRequestHeader(connection, close) is bogusly rejected
Morgan L wrote: 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. We do block, but not because of this TR. IIRC there are security issues with other values for connection, though I don't specifically remember what they are. However setting something like connection: keep-alive when the browser is not expecting that could have bad effects on other connections to that server. / Jonas
Re: XHR setRequestHeader(connection, close) is bogusly rejected
On Mar 7, 2008, at 3:02 PM, Morgan L wrote: Ah, that make sense to me. I think the current text has caused major browser engines to mistakenly stop supporting connection: close. It is easy to blindly implement whatever the standards say :-) I think it would help if a caveat were added along the lines of what you have written here. I think the connection: close example should be used to demonstrate why it might be wise for a user-agent to customize what request headers it rejects. I'm not sure that section 13.5.2 implies that connection: close can be wrong. It is true that an XHR users cannot assume that the origin server will see the connection: close header, but it is still always the case that the UA would see it. And, in the example that I provided, the goal is to tell the UA that it does not need to count this request against the max-persistent-connections-per-host limit.At least, I can't see how allowing XHR users to specify connection: close can be regarded as harmful. Thoughts? 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 but would also indicate to the UA that it should not pipeline other requests on the same connection, if it supports pipelining. 2) Never count XHR-initiated http requests towards the per-server connection limit. Given that IE has increased their per-server connection limit to 6, and since the HTTP working group is considering dropping the connection limit as a formal spec requirement, I would probably advise #2 for WebKit and have commented to that effect in the bug you cited. From the spec point of view, I think #1 makes more sense since it may be inappropriate to require #2 (thoughts from other implementors welcome). Requiring UAs to recognize Connection: close as a hint that the connection may be long-lived and should not count towards the limit is also possible as a variant of option 1. But I am not sure they should be required to also pass the header to the origin server. This does not seem necessary for the goal of bypassing the connection limit on the UA side. And it seems that an explicit XHR property for this would be more clear. Regards, Maciej
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/
