Re: [selectors-api] Return value of lookupNamespaceURI
Boris Zbarsky wrote: If the return value of lookupNamespaceURI is |undefined|, should that stringify to or undefined? Same question for |null|. Note that I'm not sure there's an obvious way to annotate this in web idl yet. Since NSResolver has now been removed, I'm closing this issue. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Why null as opposed to empty string (or either one) to resolve default namespace
Boris Zbarsky wrote: The editor's draft changes the spec to require passing null instead of to resolve the default namespace. I was just wondering why (it's a bit more of a pain to implement for me, and doesn't seem like a useful change, but maybe there's a reason I'm missing. Since NSResolver has been removed, I'm closing this issue. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] NSResolver moving nodes between documents
Boris Zbarsky wrote: What is the correct behavior if a lookupNamespaceURI call moves nodes between documents? In particular, what is the correct behavior is the Element node the call is being made on is moved to a different document during the lookupNamespaceURI call (using adoptNode)? Since NSResolver has since been removed from the spec, I'm closing this issue as it is no longer relevant. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
ISSUE-4 - what counts as content for transfer? [Progress Events]
Hi, I have put into the latest editor's draft that specs *must* define this, (for conformance), but that in the case of a request where this has not been specified(e.g. HTTP GET) user agents *should* only give the value of the body when calculating the size of content... That's unpleasantly vague, but I am not sure how to tighten it up in the spec in a way that improves on reality. Suggestions welcome :S cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [Progress Events] unsigned long long for .loaded and .total
On Wed, 18 Jun 2008 17:50:45 +0200, Olli Pettay [EMAIL PROTECTED] wrote: Hi all, I think it would be better to use unsigned long long for ..loaded and for .total. That way progress events could be more useful for streaming and file transfer applications. unsigned long isn't big enough. Yeah, I have done that for the next draft. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [access-control] Update
On Wed, 9 Jul 2008, Jonas Sicking wrote: Lastly, the 'URL' token http://dev.w3.org/2006/waf/access-control/#url should not be a full URL, and I don't think we want to depend on HTML5 for it either. Currently we seem to be allowing the syntax Access-Control-Origin: http://foo.com/bar/bin/baz.html which I think is very bad as it seems to indicate that only that page would be allowed to POST, which of course isn't something that we can enforce. This is exactly how postMessage() works and it seems nice to align with that. I am very strongly against this syntax as it gives a false sense of security. To the point where I don't think I'd be willing to implement it in firefox. The fact that postMessage allows this sounds very unfortunate and something that I will look into fixing in that spec. I don't want to carry this mistake forward into Access-Control. I have changed postMessage()'s definition to make sure that targetOrigin doesn't have a path, query, or fragment part. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [XHR] (Late) LC Comments
Geoffrey Sneddon wrote: ... I think that we should have this in XHR. Basic summary is that Firefox and Safari default to 200/OK; Opera defaults to 0/ (but does not throw INVALID_STATE_ERR); IE is inconsistent and sometimes gives 200/OK or -1/some-random-value-from-the-HTTP-response. I think we should probably just spec in XHR that 200/OK should be returned when there is no status-code/reason-phrase. We're fairly close to interoperability (as IE already sometimes does it), and nothing matches the spec currently at all, I think it should be put in XHR and not wait until my HTTP parsing spec, and waiting to see if anyone will actually implement that. ... An HTTP/1.1 response that does not contain a status line is invalid. Please do not specify behavior that requires treating broken responses as ok. Speaking of which: do you have reliable data about why this would be desirable? BR, Julian
Re: [access-control] Update
On Mon, 20 Oct 2008, Ian Hickson wrote: On Wed, 9 Jul 2008, Jonas Sicking wrote: Lastly, the 'URL' token http://dev.w3.org/2006/waf/access-control/#url should not be a full URL, and I don't think we want to depend on HTML5 for it either. Currently we seem to be allowing the syntax Access-Control-Origin: http://foo.com/bar/bin/baz.html which I think is very bad as it seems to indicate that only that page would be allowed to POST, which of course isn't something that we can enforce. This is exactly how postMessage() works and it seems nice to align with that. I am very strongly against this syntax as it gives a false sense of security. To the point where I don't think I'd be willing to implement it in firefox. The fact that postMessage allows this sounds very unfortunate and something that I will look into fixing in that spec. I don't want to carry this mistake forward into Access-Control. I have changed postMessage()'s definition to make sure that targetOrigin doesn't have a path, query, or fragment part. Now fixed to actually work. Search for host-specific. (Better names welcome.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[XHR] blocking httpOnly cookies
In bug 380418 [1] we have decided to completely block access to the Set-Cookie header through XHR. This seems like the safest way to prevent httpOnly cookies from leaking in to javascript. In addition it seems good to block access to the raw network protocol used for security and can contain user credentials. There is a risk that this will break sites since we are blocking things that used to work. However the number of legitimate uses seems pretty small (I can't think of any) and the win is high (blocking httpOnly cookies reliably as well as possible future cookie expansions) The way the blocking works is that the getResponseHeader and getAllResponseHeaders functions behave as if Set-Cookie and Set-Cookie2 was not sent by the server. / Jonas [1] https://bugzilla.mozilla.org/show_bug.cgi?id=380418
Re: [AC] Origin: null versus Origin:
On Wed, 8 Oct 2008, Adam Barth wrote: In some cases, XHR+AC will send an Origin header whose value is the empty string. This asks server operators to distinguish between a request that lacks an Origin header (like a same-site request) and a request with an empty Origin header (say from a data URL), which might be tricky in various languages like mod_security. Also, some proxies might normalize empty headers away if they represent the non-existence of a header with the empty string (as, for example, XMLHttpRequest does). A previous version of the spec sent the literal string null in these cases. It seems like this behavior is preferable. If we want to have the same behavior as postMessage, we might be able to change its origin property to use the string null in these cases too. HTML5 has now changed to do this, which I believe automatically fixes XHR+AC for you. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
New Progress Events draft
Hi folks, at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.24 you will find a new draft of the progress events spec, for your delectation... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: New Progress Events draft
Charles McCathieNevile wrote: Hi folks, at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.24 you will find a new draft of the progress events spec, for your delectation... So the spec says that for HEAD requests the size should include the size of headers. I just realized that this might be a security issue. The headers can include the users password, many times in clear text. If a site knows the size of the default headers for a given implementation, it can figure out the size of the users password by subtracting the default size from the size reported from the 'load' event from a HEAD request. / Jonas
[access-control] Security Considerations
The currently written text appears normative, but that is misleading since such sections are usually informative. Pre-flight request results are also stored to disk and so, it is a good idea to either add something to the Security Considerations or deal with it in the rest of the spec. Nikunj
[access-control] Allow example bug
Access-Control: allow example.org There is no token defined for allow. Nikunj
