[whatwg] Sort child nodes of a DOM node.
There are many cases where we want to sort child nodes of a DOM node. Many times it is TR nodes of a TBODY Right now user writes javascript code to achive that. Dont you think it is better if there was built DOM method for each node. Additionally the method will have a sort function parameter to compare elements the same way as in JavaScript Array.sort(compare_func) function compare_func(a,b){ if(isHeaderRow(a)) return -1; if(isHeaderRow(b)) return 1; if(a.textContent == b.textContent) return 0; if(a.textContent < b.textContent) return -1; return 1; } tablebody.sortChildNodes(compare_func) Use cases:- Example 1: column sorting in yahoo mail Example 2: you can sort this listing by clicking the column headers https://bugzilla.mozilla.org/buglist.cgi?short_desc=sort&short_desc_type=allwordssubstr&resolution=--- Example 2: there are bug report in mozilla asking sorting in XUL grids https://bugzilla.mozilla.org/showdependencytree.cgi?id=482890&hide_resolved=1
Re: [whatwg] URN or protocol attribute
On 6/4/2010 12:59 PM, Brett Zamir wrote: On 3/11/2010 10:44 AM, Brett Zamir wrote: On 3/11/2010 10:31 AM, Ian Hickson wrote: I would recommend following a pattern somewhat like the Web's initial development: create a proof of concept, and convince people that it's what they want. That's the best way to get a feature adopted. This is described in more detail in the FAQ: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F Ok, fair enough. I think I'll try that as a browser extension Just as a follow-up, I have now made a Firefox extension which supports two attributes on : "uris" and "alternateURIs", whereby the former takes precedence over "href", and the latter are accessible only by right-clicking links (though potentially discoverable by custom styling of such links (automatable by the extension)). My thought is that sites which have the following goals may be particularly interested: 1) Those wishing to maintain objectivity and refrain from endorsing specific sites, e.g., governments, news institutions, scholars, or sites like Wikipedia. Even for a site's internal links, use of "alternateURIs" could offer convenience (e.g., Wikipedia would no doubt wish to continue to use href to refer to its own ISBN page by default, but could use the "alternateURIs" attribute to allow right-clicks on the link to activate the URN link which in turn activates their chosen default handler, e.g., Amazon, Google Books, etc.). The same could be done for music, etc. 2) giving full user choice as to how to view the data (especially useful for information of common and particular interest to the site viewers, e.g., links to the Bible in a religious forum) 3) those wishing to try out new protocols of whatever type (not only URNs), such as chatting protocols, whether installed via web or browser extension, as the proposed markup gives them a convenient fall-back to "href", so they don't have to have dead links for those whose browsers do not support the protocol. https://addons.mozilla.org/en-US/firefox/addon/162154/ Just to elaborate a little bit further, one possible future addition which could further enhance this experience would be to design a protocol (and corresponding markup-detection mechanism), say "created:" or "wiki:" which would first check via HEAD request whether the page were created or not, and then style the link accordingly and possibly alter the URL to lead directly to the editing or alternatively, it could make HEAD requests to try out a sequence of URLs, e.g., checking whether Citizendium had an article, and if not, creating a link to the Wikipedia article if present. While this could be done potentially via the server (e.g., this extension for Mediawiki: http://www.mediawiki.org/wiki/Extension:BADI_Pages_Created_Links ), I believe allowing client-side markup to do it would facilitate use of this potential more widely, allowing wikis or open-forums to link with one another in a way which prevents wasted visits by their users. Although URNs could also be used (as supported already potentially in the above extension) to try to find encyclopedic articles (e.g., urn:name:pizza), or better yet, through a new protocol which could suggest intended uses of the information (e.g., find:urn:name:pizza?category=order, find:urn:name:pizza?category=define, etc.) and thereby avoiding hard-coding information, the "created:" suggestion above could give authors more control than they have now if they did want to suggest a particular path-way. Brett
Re: [whatwg] URN or protocol attribute
On 3/11/2010 10:44 AM, Brett Zamir wrote: On 3/11/2010 10:31 AM, Ian Hickson wrote: I would recommend following a pattern somewhat like the Web's initial development: create a proof of concept, and convince people that it's what they want. That's the best way to get a feature adopted. This is described in more detail in the FAQ: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F Ok, fair enough. I think I'll try that as a browser extension Just as a follow-up, I have now made a Firefox extension which supports two attributes on : "uris" and "alternateURIs", whereby the former takes precedence over "href", and the latter are accessible only by right-clicking links (though potentially discoverable by custom styling of such links (automatable by the extension)). My thought is that sites which have the following goals may be particularly interested: 1) Those wishing to maintain objectivity and refrain from endorsing specific sites, e.g., governments, news institutions, scholars, or sites like Wikipedia. Even for a site's internal links, use of "alternateURIs" could offer convenience (e.g., Wikipedia would no doubt wish to continue to use href to refer to its own ISBN page by default, but could use the "alternateURIs" attribute to allow right-clicks on the link to activate the URN link which in turn activates their chosen default handler, e.g., Amazon, Google Books, etc.). The same could be done for music, etc. 2) giving full user choice as to how to view the data (especially useful for information of common and particular interest to the site viewers, e.g., links to the Bible in a religious forum) 3) those wishing to try out new protocols of whatever type (not only URNs), such as chatting protocols, whether installed via web or browser extension, as the proposed markup gives them a convenient fall-back to "href", so they don't have to have dead links for those whose browsers do not support the protocol. https://addons.mozilla.org/en-US/firefox/addon/162154/ Brett
Re: [whatwg] Form validation against invisible controls
On 6/3/10, TAMURA, Kent wrote: > Oh, I'm sorry. I have found a sentence about visibility in the draft. > Where? > http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation >> If one of the controls is not being >> rendered > (e.g. it has the hidden attribute set) > then user agents may report a script error. > That's about > This sentence is about process against controls of which validation result > is invalid. > I think UA doesn't need to validate such controls. > You lost me on that one. > > The Chrome bug report is here: > http://code.google.com/p/chromium/issues/detail?id=45640 > That bug is describing an error when validating a control that cannot have focus. That's more specific from a control that is not visible. Is the issue in defining what is and what isn't focusable? > 2010/6/4 TAMURA, Kent > >> > An element is a "candidate for constraint validation" if >>> > 1. it is a validatable type, >>> >e.g. true if , false if >>> > 2. has no "disabled" attribute, >>> > 3. has no "readonly" attribute, >>> > 4. inside of a element, >>> > 5. has non-empty "name" attribute, and >>> > 6. not inside of a element. >>> > >>> > I hope ValidityState and the pseudo classes ignores 2-6. > >>> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) > > >> I'd like to propose to add another condition: >> 7. it is visible (computed 'display' property of CSS isn't 'none' and no >> 'hidden' content attribute) > >> I couldn't find exceptional rules for validating invisible controls in the >> current draft. >> Chrome 5 was released with a part of interactive validation, and we >> received a bug report about validation against invisible form controls. > >> -- >> TAMURA Kent >> Software Engineer, Google > > > > > > > -- > TAMURA Kent > Software Engineer, Google > > > >
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 3:48 PM, Aryeh Gregor > wrote: > On Thu, Jun 3, 2010 at 12:11 PM, TAMURA, Kent wrote: > > Oh, I'm sorry. I have found a sentence about visibility in the draft. > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation > >> If one of the controls is not being rendered (e.g. it has > >> the hidden attribute set) then user agents may report a script error. > > > > The Chrome bug report is > > here: http://code.google.com/p/chromium/issues/detail?id=45640 > > I think this isn't a feasible strategy to pursue. You'd have to > carefully define what's "not being rendered", and it will violate > layering massively. CSS should not be able to override constraints > set in HTML. The latter are part of the semantics of the form, and > the former is supposed to only control presentation. > > If the user can't actually change the form to match requirements, > that's a bug in the page. The browser should not try to guess what > the page really meant using some inevitably complicated heuristic. It > should respect what the page says, and make it not work. If the > browser has a UI for form validation errors, it can use that to tell > the user what the problem is in terms that the page author can > understand, so the user can report it and the page can be fixed. I posted this on the Chromium bug, but I take the sentence Kent quotes to affect only the UI shown on a validation failure, not the actual results of validation. That is, if a control fails validation and has the "hidden" attribute, validation still fails, but the UA may display a message indicating the page has an error in addition to/instead of the normal validation failure message. I agree that it would be a mistake to exclude "invisible" elements from validation, as that would be a rathole (and seems conceptually wrong to me). PK
Re: [whatwg] fixBrokenLink is not defined
On 6/3/10, Ian Hickson wrote: > On Thu, 3 Jun 2010, Garrett Smith wrote: >> >> I have noticed over the last year or so, the error "fixBrokenLink" >> often popping up. >> >> fixBrokenLink is not defined. >> >> I seem to recall at one point filing a bug but cannot find it in w3c >> Bugzilla >> http://www.w3.org/Bugs/Public/query.cgi >> >> http://dev.w3.org/html5/spec/Overview.html >> >> fixBrokenLink is not defined. > > Does this error occur with the WHATWG versions of the spec? If not, then > please report it to the W3C, not the WHATWG (it's probably an issue with > Mike's spec splitter script). >\ I'm not gonna check because that size freezes the browser.
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 12:11 PM, TAMURA, Kent wrote: > Oh, I'm sorry. I have found a sentence about visibility in the draft. > http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation >> If one of the controls is not being rendered (e.g. it has >> the hidden attribute set) then user agents may report a script error. > > This sentence is about process against controls of which validation result > is invalid. > I think UA doesn't need to validate such controls. > > The Chrome bug report is > here: http://code.google.com/p/chromium/issues/detail?id=45640 I think this isn't a feasible strategy to pursue. You'd have to carefully define what's "not being rendered", and it will violate layering massively. CSS should not be able to override constraints set in HTML. The latter are part of the semantics of the form, and the former is supposed to only control presentation. If the user can't actually change the form to match requirements, that's a bug in the page. The browser should not try to guess what the page really meant using some inevitably complicated heuristic. It should respect what the page says, and make it not work. If the browser has a UI for form validation errors, it can use that to tell the user what the problem is in terms that the page author can understand, so the user can report it and the page can be fixed.
Re: [whatwg] Comment on 6.6 Offline Web Applications
There is a way for the application to remove itself from the cache. If fetching the manifestUrl returns a 404 or 410 response, all traces of that manifestUrl are deleted from the cache. See section 6.6.4. On Thu, Jun 3, 2010 at 12:30 PM, Peter Beverloo wrote: > On Thu, Jun 3, 2010 at 15:01, Daniel Glazman > wrote: > > > > Hi there, > > > > I noticed the Application Cache does not allow to remove > > a single cached web application from the cache. Is that on > > purpose? > > I am under the impression the cache is here more an offline > > storage for webapps than a normal cache, and that in the long > > run browsers will have to implement an "Offline Web Apps" manager. > > Since the user is supposedly already provided with a dialog > > asking permission to make a webapp available offline, it makes > > sense to give him/her a way to remove a single application from > > the cache. > > > > > > Section 6.6.7 talks about expiration of cached data [1], but also > includes a few notes about removing items from the store. It > specifically states that user-agents could have a "delete > site-specific data" feature which also covers removing application > caches, but also hints towards a feature that removes caches on > request of the user. > > The API does not state a way allowing an application to remove itself > from the cache, which could be desirable for web authors. If there's > interest for such an addition I'm willing to make a proposal, as it > isn't hard to think about use-cases for such a feature. > > Regards, > Peter Beverloo > > [1] > http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#expiring-application-caches >
Re: [whatwg] fixBrokenLink is not defined
On Thu, 3 Jun 2010, Garrett Smith wrote: > > I have noticed over the last year or so, the error "fixBrokenLink" > often popping up. > > fixBrokenLink is not defined. > > I seem to recall at one point filing a bug but cannot find it in w3c Bugzilla > http://www.w3.org/Bugs/Public/query.cgi > > http://dev.w3.org/html5/spec/Overview.html > > fixBrokenLink is not defined. Does this error occur with the WHATWG versions of the spec? If not, then please report it to the W3C, not the WHATWG (it's probably an issue with Mike's spec splitter script). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Comment on 6.6 Offline Web Applications
On Thu, Jun 3, 2010 at 15:01, Daniel Glazman wrote: > > Hi there, > > I noticed the Application Cache does not allow to remove > a single cached web application from the cache. Is that on > purpose? > I am under the impression the cache is here more an offline > storage for webapps than a normal cache, and that in the long > run browsers will have to implement an "Offline Web Apps" manager. > Since the user is supposedly already provided with a dialog > asking permission to make a webapp available offline, it makes > sense to give him/her a way to remove a single application from > the cache. > > Section 6.6.7 talks about expiration of cached data [1], but also includes a few notes about removing items from the store. It specifically states that user-agents could have a "delete site-specific data" feature which also covers removing application caches, but also hints towards a feature that removes caches on request of the user. The API does not state a way allowing an application to remove itself from the cache, which could be desirable for web authors. If there's interest for such an addition I'm willing to make a proposal, as it isn't hard to think about use-cases for such a feature. Regards, Peter Beverloo [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#expiring-application-caches
[whatwg] fixBrokenLink is not defined
I have noticed over the last year or so, the error "fixBrokenLink" often popping up. fixBrokenLink is not defined. I seem to recall at one point filing a bug but cannot find it in w3c Bugzilla http://www.w3.org/Bugs/Public/query.cgi http://dev.w3.org/html5/spec/Overview.html fixBrokenLink is not defined. The error can be a bit of a distraction when reading and discussing. The WhatWG-hosted one-pager causes Firefox to freeze for upwards of forty seconds; I'm not interested in that. What is fixBrokenLink? Is it DOM-traversal done onload? That's a known cause of such delay, and the larger the document, the longer the delay. Although I do not know for certain if this is the case with the spec on whatwg.org, "fixBrokenLink" seems a suspect possibility. It would be a good idea to look into the cause of the problem and see about using another approach.
Re: [whatwg] Form validation against invisible controls
On 6/3/10 11:42 AM, João Eiras wrote: Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. Gecko doesn't necessarily paint form controls that are outside the viewport, yet ignoring those seems wrong. -Boris
Re: [whatwg] Form validation against invisible controls
Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being rendered (e.g. it has the hidden attribute set) then user agents may report a script error. This sentence is about process against controls of which validation result is invalid. I think UA doesn't need to validate such controls. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 2010/6/4 TAMURA, Kent > An element is a "candidate for constraint validation" if > 1. it is a validatable type, >e.g. true if , false if > 2. has no "disabled" attribute, > 3. has no "readonly" attribute, > 4. inside of a element, > 5. has non-empty "name" attribute, and > 6. not inside of a element. > > I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Form validation against invisible controls
On Thu, 2010-06-03 at 08:54 -0700, Tab Atkins Jr. wrote: > On Thu, Jun 3, 2010 at 8:42 AM, João Eiras wrote: > > On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent wrote: > > > >> > >> > >>> > An element is a "candidate for constraint validation" if > >>> > 1. it is a validatable type, > >>> >e.g. true if , false if > >>> > 2. has no "disabled" attribute, > >>> > 3. has no "readonly" attribute, > >>> > 4. inside of a element, > >>> > 5. has non-empty "name" attribute, and > >>> > 6. not inside of a element. > >>> > > >>> > I hope ValidityState and the pseudo classes ignores 2-6. > >> > >>> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) > >> > >> > >> I'd like to propose to add another condition: > >> 7. it is visible (computed 'display' property of CSS isn't 'none' and no > >> 'hidden' content attribute) > >> > > > > You'd need to check the visibility or display also of all ancestors, that > > opacity is not 0, that the bounding box has enough size to render the form > > to the user and etc. > > That's quite complicated to specify. > > > > Would be easier to tell that user agents might chose to ignore form controls > > that they do not *paint* if that is possible for the UA to implement. > > That's even worse - that defeats the time-honored trick to hide > something visually without hiding it in any other way of absolutely > positioning it off the screen. It might even mean that elements > currently off the screen (but that can be scrolled to) wouldn't > validate. > > ~TJ But we really shouldn't be positioning things 'off screen' anyway. You should be considering people who aren't viewing the site through the traditional computer & web browser. What about people who are using a speech or Braille browser? What about search engines (most of which specify in their terms that what you give them should equal the user experience) and basically any service that legitimately scrapes content (think web snippets, etc that some browsers are implementing) Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 8:42 AM, João Eiras wrote: > On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent wrote: > >> >> >>> > An element is a "candidate for constraint validation" if >>> > 1. it is a validatable type, >>> > e.g. true if , false if >>> > 2. has no "disabled" attribute, >>> > 3. has no "readonly" attribute, >>> > 4. inside of a element, >>> > 5. has non-empty "name" attribute, and >>> > 6. not inside of a element. >>> > >>> > I hope ValidityState and the pseudo classes ignores 2-6. >> >>> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) >> >> >> I'd like to propose to add another condition: >> 7. it is visible (computed 'display' property of CSS isn't 'none' and no >> 'hidden' content attribute) >> > > You'd need to check the visibility or display also of all ancestors, that > opacity is not 0, that the bounding box has enough size to render the form > to the user and etc. > That's quite complicated to specify. > > Would be easier to tell that user agents might chose to ignore form controls > that they do not *paint* if that is possible for the UA to implement. That's even worse - that defeats the time-honored trick to hide something visually without hiding it in any other way of absolutely positioning it off the screen. It might even mean that elements currently off the screen (but that can be scrolled to) wouldn't validate. ~TJ
Re: [whatwg] Form validation against invisible controls
On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent wrote: > An element is a "candidate for constraint validation" if > 1. it is a validatable type, >e.g. true if , false if > 2. has no "disabled" attribute, > 3. has no "readonly" attribute, > 4. inside of a element, > 5. has non-empty "name" attribute, and > 6. not inside of a element. > > I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) You'd need to check the visibility or display also of all ancestors, that opacity is not 0, that the bounding box has enough size to render the form to the user and etc. That's quite complicated to specify. Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls.
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 8:16 AM, TAMURA, Kent wrote: >> > An element is a "candidate for constraint validation" if >> > 1. it is a validatable type, >> > e.g. true if , false if >> > 2. has no "disabled" attribute, >> > 3. has no "readonly" attribute, >> > 4. inside of a element, >> > 5. has non-empty "name" attribute, and >> > 6. not inside of a element. >> > >> > I hope ValidityState and the pseudo classes ignores 2-6. >> >> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) > > I'd like to propose to add another condition: > 7. it is visible (computed 'display' property of CSS isn't 'none' and no > 'hidden' content attribute) > I couldn't find exceptional rules for validating invisible controls in the > current draft. > Chrome 5 was released with a part of interactive validation, and we received > a bug report about validation against invisible form controls. Adding @hidden to the list of things that skip validation is good. Adding display:none is not. That's a big layering violation that we authors have to suffer through with screen readers already. I'd greatly prefer not muddying the waters there. ~TJ
[whatwg] Form validation against invisible controls
> An element is a "candidate for constraint validation" if > 1. it is a validatable type, >e.g. true if , false if > 2. has no "disabled" attribute, > 3. has no "readonly" attribute, > 4. inside of a element, > 5. has non-empty "name" attribute, and > 6. not inside of a element. > > I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] WebSockets: UDP
On Thu, Jun 3, 2010 at 7:28 AM, Erik Möller wrote: > [...] > One thing to remember here is that browsers have other means for > communication as well. I'm not saying we shouldn't support reliable messages > over UDP, but just pointing out the option. Yep - the relevant use cases ought to be supported decently by the platform, but not necessarily by this extension to the platform (it might be a different extension or it might be (probably is) supported already). >> - Protection against an attacker initiating a legitimate socket with a >> user and then redirecting it (with some kind of IP (un)hijacking) to a >> service behind the user's firewall (which isn't a problem when using >> TCP since the service will ignore packets when it hasn't done the TCP >> handshake; but UDP services might respond to a single packet from the >> middle of a websocket stream, so every single packet will have to be >> careful not to be misinterpreted dangerously by unsuspecting >> services). > > I don't quite follow what you mean here. Can you expand on this with an > example? I was thinking something like: A host at IP 11.11.11.11 on the public internet runs some UDP service, like DNS or TFTP or something a bit more secure. That service is restricted so it only responds to packets received from IP 22.22.22.22 (a trusted user). The UDP Web Socket handshake is carefully constructed so that it won't trigger dangerous behaviour in any of those services (like how the TCP Web Socket uses a safe HTTP-ish handshake). An attacker hijacks the IP 11.11.11.11 from the perspective of the user (by advertising new routes near the user), so the user's packets to that address go to the attacker. The attacker gets the user to visit a web page which sets up a UDP Web Socket with the attacker's server at 11.11.11.11, doing all the handshake authentication correctly. The attacker then releases its hijacked address, so any subsequent Web Socket packets will go to the original restricted service. Since they're being received from the trusted user, the service will trust them. Since the web browser has already done the Socket handshake, it will believe it's talking to a legitimate Web Socket server and will continue sending whatever data packets the attacker's script tells it to. The service will then be receiving and responding to attacker-controlled packets, and will never have seen the carefully constructed handshake that's designed to protect it. That's not a danger for TCP services since they'll reject unexpected packets from the middle of a TCP stream, but UDP services may accept packets from the middle of a UDP Web Socket stream. So it's not sufficient to carefully construct the Web Socket handshake packets to not trigger unwanted behaviour in non-Socket services. Every data packet sent on the Socket has to be carefully constructed too. (This might be a largely impractical or pointless attack, and there's probably much easier ways to attack the exposed service, but I don't know enough about security to judge that. Also I don't know what packet construction would be sufficiently careful. But it seems like a possible new concern that's introduced when using UDP in this context.) -- Philip Taylor exc...@gmail.com
Re: [whatwg] WebSocket set-cookie
On Fri, 07 May 2010 16:32:38 +0200, Simon Pieters wrote: establish a WebSocket connection [[ 41. ... If the entry's name is "set-cookie" or "set-cookie2" or another cookie-related field name If the relevant specification is supported by the user agent, handle the cookie as defined by the appropriate specification, with the resource being the one with the host host, the port port, the path (and possibly query parameters) resource name, and the scheme http if secure is false and https if secure is true. [COOKIES] If the relevant specification is not supported by the user agent, then the field must be ignored. ]] At this point, the handshake can still fail. It seems bad to set cookies if the handshake fails. We want to process set-cookie when the handshake has succeeded (but before changing readyState and firing 'open'). ...but still in that same task that changes readyState and fires 'open'. -- Simon Pieters Opera Software
[whatwg] Comment on 6.6 Offline Web Applications
Hi there, I noticed the Application Cache does not allow to remove a single cached web application from the cache. Is that on purpose? I am under the impression the cache is here more an offline storage for webapps than a normal cache, and that in the long run browsers will have to implement an "Offline Web Apps" manager. Since the user is supposedly already provided with a dialog asking permission to make a webapp available offline, it makes sense to give him/her a way to remove a single application from the cache.