Re: [selectors-api]
On Tue, 19 Feb 2008, Anne van Kesteren wrote: My suggestion was to allow the implementation to throw as soon as it detects any sort of misbehavior from the NSResolver. Anne didn't like it. Given that the implementation isn't allowed to do this, what _is_ it allowed to do to comply with the deal with broken or malicious NSResolvers text? I think it has to go like this: 1. Get default namespace / resolve namespace prefixes 2. Run the group of selectors over the current DOM And I like to believe that this is what the specification requires. But maybe we should make it explicit in the method section that step 1 has to happen first and that user agents are not allowed to do both at the same time. So even prefixes that are never going to match in the current document have to be checked? e.g. if the document has no child element that has no siblings, and the author does this: :not(a1|*):not(a2|*):not(a3|*):not(a4|*):not(a5|*) :only-child, ...do we have to call NSResolver for a1..a5, even though we know no element will ever mach that selector, just in case the resolver mutates the document at some point to make it that an element matches it? That seems like optimising for the wrong case in a pretty big way. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [selectors-api]
Boris Zbarsky wrote: Anne van Kesteren wrote: 1. Get default namespace / resolve namespace prefixes 2. Run the group of selectors over the current DOM If the spec did require this, that would make me somewhat happier, but it wouldn't address the issue of what implementations are allowed to actually do to stop misbehaving NSResolvers. I can modify the spec to require that, I just need to figure out the best way to write it. But then I don't think there is anything special an implementation would need to do to deal with the a misbehaving resolver (beyond what the spec already requires for unexpected return values and exceptions thrown by it), since any modifications performed by the resolver would occur before searching the DOM. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api]
Lachlan Hunt wrote: I can modify the spec to require that, I just need to figure out the best way to write it. But then I don't think there is anything special an implementation would need to do to deal with the a misbehaving resolver (beyond what the spec already requires for unexpected return values and exceptions thrown by it), since any modifications performed by the resolver would occur before searching the DOM. The spec says: User agents should ensure they remain stable when facing a hostile NSResolver object. Potentially hostile behaviour includes: * Returning inconsistent results; * Hanging; * Changing the DOM during the operation. The only solution I'm seeing so far to a hanging NSResolver is terminating that script at some point. Once that's happened, the UA cannot reasonably perform the query operation, since the namespaces haven't been resolved (or some of them haven't been resolved). Is it supposed to go ahead and just return random data? Anne says it can't throw. What _can_ it do? -Boris
Re: [selectors-api]
Anne van Kesteren wrote: On Tue, 19 Feb 2008 10:43:14 +0100, Boris Zbarsky [EMAIL PROTECTED] wrote: The only solution I'm seeing so far to a hanging NSResolver is terminating that script at some point. Is that what you're doing for treewalker node filters? Yes. I'm not sure why we should specifically define what to do with a hanging NSResolver case. I think it should be treated identically to a hanging script. (Ideally they run forever with the UI still being usable.) Agreed. I think it's outside the scope of the spec to try to deal with this. I think the text about behaving in the face of a hostile NSResolver should be informative rather than normative (not sure if it already is), and possibly live in a security considerations section. / Jonas
SVG copy and paste between applications?
Chaals, Erik Irène, Are we near being able to copy and paste svg symbols that are externally referenced with use between applications? regards Jonathan Chetwynd Accessibility Consultant on Media Literacy and the Internet In Amaya, open: http://peepo.co.uk/temp/use-external.svg copy, paste and save the sun symbol: use x=200 y=150 width=200 height=200 xlink:href=http://upload.wikimedia.org/wikipedia/commons/ 5/50/Weather-icons.svg#sunny / in a new document then open in Opera 9.5
Re: [selectors-api]
On Tue, 19 Feb 2008 10:07:19 +0100, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 19 Feb 2008, Anne van Kesteren wrote: My suggestion was to allow the implementation to throw as soon as it detects any sort of misbehavior from the NSResolver. Anne didn't like it. Given that the implementation isn't allowed to do this, what _is_ it allowed to do to comply with the deal with broken or malicious NSResolvers text? I think it has to go like this: 1. Get default namespace / resolve namespace prefixes 2. Run the group of selectors over the current DOM And I like to believe that this is what the specification requires. But maybe we should make it explicit in the method section that step 1 has to happen first and that user agents are not allowed to do both at the same time. So even prefixes that are never going to match in the current document have to be checked? Well, the intent was more that prefixes are resolved before checking the DOM at all. If the UA doesn't think it needs to check prefixes that's fine (though it would probably still have to check the default namespace). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Security-sensitive headers
On Tue, 19 Feb 2008 02:21:31 +0100, Collin Jackson [EMAIL PROTECTED] wrote: Approach 1: Create a prefix denoting headers that are determined by the user agent and cannot be overwritten by unprivileged JavaScript. For example, UA- or Sec-. This is the approach we prefer. Given that older clients and malicious clients will be vulnarable why is that not a problem going forward? I'm fine with doing this though. [...] but under the current specification we'd have to chose a header name that starts with Proxy-. There have been many other proposals for new security-related HTTP headers (e.g. content restrictions) so it would be nice to solve this issue in general. Comments like this do encourage me to introduce Sec- so we don't get a whole bunch of fake Proxy- headers. (Note that not all clients blaclist everything Proxy- yet.) Another related issue that would be good to standardize is the handling of the Cookie header. Internet Explorer 6 and 7 doesn't appear to allow Cookies to be set using XMLHttpRequest at all. Firefox 2 allows pages to use XMLHttpRequest to set a Cookie header, but merges the user-set header with the user agent header: Cookie: [actual cookies values]; [user-set Cookie header value] I've heard some arguments for removing Cookies from cross-site XMLHttpRequests, which indicates to me that the Cookie header might be a good candidate for adding to the security-sensitive list. What are those arguments? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api]
On Tue, 19 Feb 2008 10:43:14 +0100, Boris Zbarsky [EMAIL PROTECTED] wrote: The only solution I'm seeing so far to a hanging NSResolver is terminating that script at some point. Is that what you're doing for treewalker node filters? I'm not sure why we should specifically define what to do with a hanging NSResolver case. I think it should be treated identically to a hanging script. (Ideally they run forever with the UI still being usable.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api]
Lachlan Hunt wrote: Boris Zbarsky wrote: Anne van Kesteren wrote: To ensure that naïve implementors don't overlook the potential issue here. An implementation of NSResolver can be provided by the script author as the specification explains and the script author can do all kinds of weird things that don't match a conforming implementation of NSResolver (such as mutating the DOM tree). Is a conforming querySelector implementation allowed to throw an exception when this happens? No. It is only allowed to throw an exception when the text says so. In that case, can you please describe what is a conforming behavior for a querySelector (or querySelectorAll) implementation if: 1) It needs to call the NSResolver on every match attempt 2) The NSResolver mutates the DOM on every match attempt That would seem to be a very inefficient implementation, though I suppose the spec should deal with the possibility in one way or another. If you're going to require the implementation to deal with NSResolvers which do random stuff but put too many constraints on what it's allowed to do to deal with them (as you are), you make an implementation impossible. Now maybe you're actually requiring that the number of calls to the NSResolver for any given selector and initial DOM tree is bounded in the face of all possible mutations by the NSResolver and that hence the DOM will at some point stabilize and it will be possible to return the things the spec requires be returned. But if that's a constraint you want to place on implementations, you should probably spell it out clearly. Note that in Gecko I suspect the NSResolver would only be called during the parsing of the selector, so we could in fact return the things the spec requires... on the post-mutation DOM, not the pre-mutation one. It's not clear to me from the spec whether this would be conformant. It's not clear to me what the spec should say to resolve this issue. Do you have any suggestions? For what it's worth, the DOM-XPath spec more or less dictates that the NSResolver is only used during parsing of the expression. I think this is a very acceptable requirement given how much hassle arises if the implementation were to use the NSResolver were used while executing the expression. The exact same applies to the selectors API IMHO. I.e. I don't see a need to allow an implementation like the one described by Boris. / Jonas
Re: [selectors-api] Selectors API comments: section 2
On Tue, 19 Feb 2008 11:31:50 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: I do sort of think that it's a pity to disallow a selectors implementation in a browser from implementing additional selectors on top of the ones in the CSS implementation, for example for the reasons Boris mentioned. I don't feel very strongly about it, but I'm wondering what the rationale for forbidding it is. So that the API stays consistent. If a new selector comes up that only makes sense in either we can always revisit this approach. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Pipelining Control Proposal
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 XHR object. If pipeline property is set to true, when send is called, the XHR request SHOULD be pipelined over one of the currently active connection, even if all connections to the target server are currently waiting for a response. That is, the request should be pipelined if necessary to send it immediately. If there is an available connection is alive, but no responses are waiting, the request should be sent on this connection (just as a non-pipelined request would be). If the pipeline property is set to false, the XHR request SHOULD NOT be pipelined even if the user agent supports and would otherwise pipeline the request. The pipeline property may also be set to another XHR object with an open connection, in which case the request should be pipelined on that specific TCP connection. For example: var xhr1 = new XMLHttpRequest(); xhr1.open(GET,/resource1,true); xhr1.send(null); var xhr2 = new XMLHttpRequest(); xhr2.open(GET,/resource2,true); xhr2.pipeline = xhr1; xhr2.send(null); In this example, both requests should be sent over the same TCP connection. The GET for resource1 should be sent and the GET for resource2 should be pipelined behind the first request on the same connection. If a connection has been marked as an extra connection with the extraConnection property on the XHR object (see the extra connection proposal), that connection should not be used for pipelined requests unless another XHR request explicitly specifies that connection, in which case that XHR request SHOULD be pipelined on that connection. (This is because the extra connection request is generally to be used for long-lived responses that are kept open for server-sent messages. Requests that are sent behind such a request may never receive a response, which should not be the default behavior, but may be explicitly chosen to achieve full asynchronous duplex communication on a single TCP connection, a highly valuable capability channels with server-sent messages.) If a network error occurs while servicing a request, any pipelined requests that are queued behind the first request SHOULD NOT automatically be retried by the user agent. A network error in response to the first request should cause an error condition for both the first XHR object and all subsequent pipelined XHR objects per normal XHR behavior. It is the responsible of the application author to retry the request if desired. Note that RFC 2616 states that non-idempotent methods should not be pipelined. However, this SHOULD NOT be enforced by the user agent. Authors should follow the recommendation of RFC 2616, but if they do not and choose to pipeline a non-idempotent request, the user agent should oblige.
Extra Connection Support Proposal
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. 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: Multipart Support Proposal
On Tue, 19 Feb 2008 16:55:18 +0100, Kris Zyp [EMAIL PROTECTED] wrote: Multipart Support Do we really want to overload XMLHttpRequest with comet-style functionality? XMLHttpRequest is already quite complex. I'd personally (and I think the company I represent would agree) much rather go with the server-sent events proposal in HTML 5. Remove some functionality from it as proposed by the WebKit guys so that it becomes easier to implement and author and ship it. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Multipart Support Proposal
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 to true. When the
response begins to stream into the user agent, the XHR response sequence should
be triggered for each part as it is received, and the user agent should not
wait for the entire HTTP response to be received. When multipart is enabled,
the user agent should perform multipart handling for responses with a MIME type
of any multipart type. That is, when a response includes a Content-Type
header with value of multipart/* where the subtype can be any value, then
multipart handling should be performed.
When handling a multipart message, the XHR object should expose an
additional property multipartState. The multipartState property should
provide the status of the XHR request exactly as the readyState property
would when multipart handling is not enabled. As each part is received is
being received, the multipartState should be 3 and when the response is
finished the multipartState should be 4.
The XHR object should also provide two additional methods,
getPartHeader(headerName) and getAllPartHeaders(). These methods should
provide access to the headers of each part. When a part is encountered, and
the headers have been received (readyState of 2 or higher), the
getPartHeader can be called to with a name of a header, and the method
should return the value for that header within the currently processed part.
The getAllPartHeaders can be called after the headers have been received and
it should return the entirety of the header block text for that part.
When the leading boundary prior to each part is received, the
onreadystatechange handler should be called with the readyState property set
to 1, and responseText should be an empty string. When the headers have been
received for the part (that is, two line breaks are encountered), the
onreadystatechange handler should be called with the readyState property set
to 2 and the getPartHeader and getAllPartHeaders should be able to return
header information. When any of the content of the part is received, the
onreadystatechange handler should be called with the readyState property set
to 3 and the responseText property with the available content. This may be
called multiple times as content is streamed in. When the ending boundary is
encountered, the onreadystatechange handler should be called with the
readyState property set to 4, and the responseText property with the content
of the part and the onload handler should be called. Note that since the
ending boundary is the starting boundary for the next part the beginning
onreadystatechange handler should be called for the next part immediately
following the last call for the previous part.
The following is an example of usage:
var xhr = new XMLHttpRequest;
xhr.multipart = true;
xhr.open(GET,/resource, true);
xhr.onreadystatechange=function() {}
xhr.send(null);
message/http Support
In addition to multpart/* handling, the message/http MIME
should also be handled. The message/http type consists of 1 or more
HTTP response messages. This format only differs from multipart/message
in that there are no boundaries. Boundaries are not necessary with HTTP
messages since each message defines it's own ending (via the
Content-Length header or chunked encoding termination) so boundaries
are unnecessary overhead. Each HTTP message would be treated as a
part, with the responseText being set to the response entity and
getPartHeader and getAllPartHeaders accessing the headers. In addition,
the XHR object's status and statusText properties would reflect the
status values in each of the contained HTTP messages.
Differences from Mozilla Implementation
Multipart support has been implemented in Mozilla with some notable
usability issues that are fixed in this proposal. First, there is no way to
detect when a multipart response is finished since each part triggers a
readyState of 4. Therefore this proposal adds a multipartState property
provides overall response status. Second, Mozilla provides no access to the
headers in each part. This is corrected by adding the getPartHeaders and
getAllPartHeaders methods (which behave very similar to getResponseHeader
and getAllResponseHeaders, except on the part instead of the whole
response). Third, when multipart is enabled, Mozilla only handles responses
with the MIME type of multipart/x-mixed-replace. This greatly limits the use
of more meaningful and accurate MIME types such as multipart/mixed,
multipart/message, and message/http. This proposal removes this limitation
and specifies that multipart handling can be used for any multipart response.
Re: Pipelining Control Proposal
Just about every feature available to web developers is non-uniformly available! Pipelining is vastly more broadly available than just about anything we have available to us. And arguments based on the unreliability of pipelining have still lacked any hard evidence. Dropping a proposal shouldn't be based on FUD. The bottom line is even if some proxies don't handle pipelining, application authors should have the choice. Authors are aware of the risks and can make informed decisions when other browser features aren't uniformly available, and they should have the choice in this matter as well. We shouldn't just assume that all developers are stupid and just throw are hands up in despair that we can never have pipelining. That won't lead to progress. This is our best opportunity to have an inroad to pipelining, via consenting authors. Kris - Original Message - From: 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 risk of creating websites that only work for some users. I.e. for users with a direct connection to the server the website would work fine, but for users sitting behind a proxy or a firewall the site would break. I doubt we can expect web authors to appropriately write fallback code when in their testing pipelineing will work fine. / Jonas Kris Zyp wrote: 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 XHR object. If pipeline property is set to true, when send is called, the XHR request SHOULD be pipelined over one of the currently active connection, even if all connections to the target server are currently waiting for a response. That is, the request should be pipelined if necessary to send it immediately. If there is an available connection is alive, but no responses are waiting, the request should be sent on this connection (just as a non-pipelined request would be). If the pipeline property is set to false, the XHR request SHOULD NOT be pipelined even if the user agent supports and would otherwise pipeline the request. The pipeline property may also be set to another XHR object with an open connection, in which case the request should be pipelined on that specific TCP connection. For example: var xhr1 = new XMLHttpRequest(); xhr1.open(GET,/resource1,true); xhr1.send(null); var xhr2 = new XMLHttpRequest(); xhr2.open(GET,/resource2,true); xhr2.pipeline = xhr1; xhr2.send(null); In this example, both requests should be sent over the same TCP connection. The GET for resource1 should be sent and the GET for resource2 should be pipelined behind the first request on the same connection. If a connection has been marked as an extra connection with the extraConnection property on the XHR object (see the extra connection proposal), that connection should not be used for pipelined requests unless another XHR request explicitly specifies that connection, in which case that XHR request SHOULD be pipelined on that connection. (This is because the extra connection request is generally to be used for long-lived responses that are kept open for server-sent messages. Requests that are sent behind such a request may never receive a response, which should not be the default behavior, but may be explicitly chosen to achieve full asynchronous duplex communication on a single TCP connection, a highly valuable capability channels with server-sent messages.) If a network error occurs while servicing a request, any pipelined requests that are queued behind the first request SHOULD NOT automatically be retried by the user agent. A network error in response to the first request should cause an error condition for both the first XHR object and all subsequent pipelined XHR objects per normal XHR behavior. It is the responsible of the application author to retry the request if desired. Note that RFC 2616 states that non-idempotent methods should not be pipelined. However, this SHOULD NOT be enforced by the user agent. Authors should follow the recommendation of RFC 2616, but if they do not and choose to pipeline a non-idempotent request, the user agent should oblige.
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: multipart, server-sent events, and
On Feb 19, 2008, at 11:12 AM, Robert Sayre wrote: On Feb 19, 2008 1:50 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: Probably the appropriate forum to make this proposal would be the IETF HTTP Working Group. I'll join the appropriate mailing list if others are interested in pursuing it there. In advance of this, we could agree by convention on an unofficial Connection: x-pipeline value to see how well this proposal works in practice. Thoughts? It's a good idea, but some proxies forward hop-by-hop headers. :( See http://www.mnot.net/blog/2007/06/20/proxy_caching That document mentions some proxies forwarding headers listed in Connection, and some specific fixed hop-by-hop headers (Trailer, TE, Upgrade). But do any proxies actually forward the Connection header itself? FWIW, the next Firefox beta will have pipelining enabled for https. I won't be surprised if we hit bad bugs. Falling back to https in combination with your proposed connection token might be a fine idea. That would certainly remove the risk of mistaken forwarding of the Connection header. Regards, Maciej
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: multipart, server-sent events, and
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. Firefox allows users to enable pipelining and according to Robert, it will be enabled by default. This indicates that pipelining has been tested by browsers in the wild, it is not without some validity. They both use heuristics to determine if pipelining is appropriate. This most notable heuristic is disabling pipelining for IIS servers, which is another case where origin server knowledge properly facilitates informed consent. where it will fail, it cannot detect the failure up front or even after the fact. The result of proceeding in the face of failure will not be a clear failure but rather data corruption. While less than 1% of users may experience these kinds of problems, an Once again, why not let authors make this decision? There are other browser quirks that lead to unpredicable results. If developers think %1 is worth risk, they should be able to do that. There may be clever ways to work around these issues that we haven't even thought of yet. And once again some developers are developing for intranets where the routes are controlled. Why penalize them due to uncertainties on the open internet? XMLHttpRequest is much different than having some menu option to enable pipelining. Many web developers use frameworks that wrap XHR, but those that actually directly interact with XHR are usually doing so because they want precise control of their requests. Why not let them have it? They can read the literature on how dangerous it is and choose if it is worth it. The fact that Opera and now Firefox are doing so broadly certainly would suggest that it is a valid enough choice that devs could at least opt-in. I would ask further why HTTP pipelining is especially more important for XHR than for normal fetching of HTTP resources. Fundamentally, it is nothing more than a performance optimization, and even the most AJAXey of sites makes many more ordinary resource requests than XHR requests. I am not opposed to pipelining of all resources, but XHR provides an API for opt-in, so devs can explicitly choose to pipeline. Second, sometimes pipelining can actually be detrimental, if a slow resource ends up having several requests that become queued behind it. With explicit pipelining, developers can have control and ensure the correct delegation of pipeline requests for optimum efficiency. Finally, in particular with comet-style long-lived responses, being able to control pipelining is even more important. One can pipeline requests over the long-lived response connection to create a duplex communication over a single TCP connection. One can pipeline requests to another connection to ensure that responses are received properly. There is simply no way to do this efficiently otherwise, and comet-style communication requires two connections for duplex conversation even though it is fully with the means of HTTP do it over a single connection. I think we need some research before making a decision either way. I just wanted to make clear the nature of the risks, and in particular that content author opt-in was not sufficient to fully mitigate them. Freedom is not intended to be a risk mitigation. Opt-in is a choice to accept risk, not mitigate it. appropriate for this purpose. So I would propose that we define an HTTP response header field of Connection: pipeline to indicate that the server supports pipelining and encourages its use for this particular connection. I don't think this is a bad idea. But for the reasons stated above, I still think it is important to have an XHR API to suggest pipelining. Thanks for your feedback. Kris
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/
Re: Pipelining Control Proposal
An important difference is that most other features non-uniform across browser, not across users. A web developer can test the browsers they are interested in supporting. It's much harder for the developer to test the various user environments that are going to affect pipelining. Don't get me wrong, I'd love pipelining as much as everyone else. I'm just not convinced that adding it through XMLHttpRequest is a solution that will help. Another worry I have with the proposal is that I think XMLHttpRequest would be the wrong place to implement this. It's really a HTTP feature that should be implemented unrelated to XMLHttpRequest so that the rest of the browser can make use of it. Once we figure out a way to do it safely that is. / Jonas Kris Zyp wrote: Just about every feature available to web developers is non-uniformly available! Pipelining is vastly more broadly available than just about anything we have available to us. And arguments based on the unreliability of pipelining have still lacked any hard evidence. Dropping a proposal shouldn't be based on FUD. The bottom line is even if some proxies don't handle pipelining, application authors should have the choice. Authors are aware of the risks and can make informed decisions when other browser features aren't uniformly available, and they should have the choice in this matter as well. We shouldn't just assume that all developers are stupid and just throw are hands up in despair that we can never have pipelining. That won't lead to progress. This is our best opportunity to have an inroad to pipelining, via consenting authors. Kris - Original Message - From: 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 risk of creating websites that only work for some users. I.e. for users with a direct connection to the server the website would work fine, but for users sitting behind a proxy or a firewall the site would break. I doubt we can expect web authors to appropriately write fallback code when in their testing pipelineing will work fine. / Jonas Kris Zyp wrote: 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 XHR object. If pipeline property is set to true, when send is called, the XHR request SHOULD be pipelined over one of the currently active connection, even if all connections to the target server are currently waiting for a response. That is, the request should be pipelined if necessary to send it immediately. If there is an available connection is alive, but no responses are waiting, the request should be sent on this connection (just as a non-pipelined request would be). If the pipeline property is set to false, the XHR request SHOULD NOT be pipelined even if the user agent supports and would otherwise pipeline the request. The pipeline property may also be set to another XHR object with an open connection, in which case the request should be pipelined on that specific TCP connection. For example: var xhr1 = new XMLHttpRequest(); xhr1.open(GET,/resource1,true); xhr1.send(null); var xhr2 = new XMLHttpRequest(); xhr2.open(GET,/resource2,true); xhr2.pipeline = xhr1; xhr2.send(null); In this example, both requests should be sent over the same TCP connection. The GET for resource1 should be sent and the GET for resource2 should be pipelined behind the first request on the same connection. If a connection has been marked as an extra connection with the extraConnection property on the XHR object (see the extra connection proposal), that connection should not be used for pipelined requests unless another XHR request explicitly specifies that connection, in which case that XHR request SHOULD be pipelined on that connection. (This is because the extra connection request is generally to be used for long-lived responses that are kept open for server-sent messages. Requests that are sent behind such a request may never receive a response, which should not be the default behavior, but may be explicitly chosen to achieve full asynchronous duplex communication on a single TCP connection, a highly valuable capability channels with server-sent messages.) If a network error occurs while servicing a request, any pipelined requests that are queued behind the first request SHOULD NOT automatically be retried by the user agent. A network error in response to the first request should cause an error condition for both the first XHR object and all subsequent pipelined XHR objects per normal XHR behavior. It is
