Re: XDomainRequest Integration with AC

Jonas Sicking wrote: Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I’m in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas’s proposal. http://lists.w3.org/Archives/Public/public-webapps/2008

Re: XDomainRequest Integration with AC

Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I’m in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas’s proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please

RE: XDomainRequest Integration with AC

Jonas said: 'url' is parsed as an absolute URL using the internal parser used for normal URL parsing, but if the resulting URL contains anything other than scheme, domain and port then access should be denied. I.e. if the url contains a path, a query string a fragment or similar, the header is con

Re: XDomainRequest Integration with AC

Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I’m in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas’s proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please

RE: XDomainRequest Integration with AC

On Fri, 18 Jul 2008, Eric Lawrence wrote: > > In the scenario you described, the threat was that there would be > information disclosure against an unsuspecting redirector in the middle > of a redirection chain. > > It's not clear to me how providing read-access to the final destination > (whi

RE: XDomainRequest Integration with AC

In the scenario you described, the threat was that there would be information disclosure against an unsuspecting redirector in the middle of a redirection chain. It's not clear to me how providing read-access to the final destination (which must opt-in to such access using an Access-Control res

Re: XDomainRequest Integration with AC

On Jul 18, 2008, at 5:15 PM, Eric Lawrence wrote: Can you elaborate on the scenario you’re concerned about? I cannot think of a scenario matching your description that could not be exploited using HTML4 Forms alone. Forms do not give you read access to the target of the redirect, whethe

RE: XDomainRequest Integration with AC

Can you elaborate on the scenario you're concerned about? I cannot think of a scenario matching your description that could not be exploited using HTML4 Forms alone. Thanks! Eric Lawrence Program Manager - IE Security Want to view and tamper with HTTP(S) traffic? Try http://www.fiddler2.com

Re: XDomainRequest Integration with AC

On Jul 18, 2008, at 4:56 PM, Eric Lawrence wrote: The specific concern with redirections is that we know of instances where redirection systems are in use that do not currently support addition of custom response headers, and cannot be trivially updated to add such headers. These redirect

Re: XDomainRequest Integration with AC

On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I’m in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas’s proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discu

RE: XDomainRequest Integration with AC

The specific concern with redirections is that we know of instances where redirection systems are in use that do not currently support addition of custom response headers, and cannot be trivially updated to add such headers. These redirection systems include legacy C++ applications whose source

XDomainRequest Integration with AC

I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, Th

Re: [D3E] Possible Changes to Mutation Events

Doug Schepers wrote: Hi, Jonas- Jonas Sicking wrote (on 7/18/08 2:51 PM): Well, I'd start by asking what the rationale is for mutation events at all :) They seem to only solve the very simple cases where all parties that mutate the page cooperate nicely with each other and with the parties t

Re: [D3E] Possible Changes to Mutation Events

Maciej Stachowiak wrote: On Jul 17, 2008, at 5:51 PM, Jonas Sicking wrote: Doug Schepers wrote: Jonas proposes two substantive changes to this: * DOMNodeRemoved and DOMNodeRemovedFromDocument would be fired after the mutation rather than before * DOM operations that perform multiple sub-o

Re: Proposal for an extension XMLHttpRequest to allow sending files

On Fri, Jul 18, 2008 at 2:36 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > I wonder if it is possible to make resumability more automatic, somewhat > like the way If-Range is used to do resumable downloads. But manual slicing > does seem like an ok solution. We have been thinking about that

Re: [D3E] Possible Changes to Mutation Events

On Jul 18, 2008, at 11:51 AM, Jonas Sicking wrote: In mozilla we have never implemented DOMNodeRemovedFromDocument or DOMNodeInsertedIntoDocument due to its high cost. Likewise I doubt that we'll implement DOMDescendantRemovedFromDocument. I'm not sure what other vendors have done about the

Re: Proposal for an extension XMLHttpRequest to allow sending files

On Jul 18, 2008, at 9:58 AM, Aaron Boodman wrote: On Thu, Jul 17, 2008 at 4:06 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: On Jul 17, 2008, at 3:53 PM, Aaron Boodman wrote: I have two minor concerns with this proposal, both in the cases where it differs from Gears: 1. Combining the

New file I/O build

Hi folks, if you want to play around with the file I/O stuff, we have released another Opera build on desktop platforms (Windows, Mac, Linux, FreeBSD) that incorporates it - again for the moment only enabled for widgets. This is an experimental build, so usual warnings and disclaimers appl

Re: [D3E] Possible Changes to Mutation Events

On Jul 17, 2008, at 5:51 PM, Jonas Sicking wrote: Doug Schepers wrote: Jonas proposes two substantive changes to this: * DOMNodeRemoved and DOMNodeRemovedFromDocument would be fired after the mutation rather than before * DOM operations that perform multiple sub-operations (such as movin

Re: [D3E] Possible Changes to Mutation Events

Hi, Jonas- Jonas Sicking wrote (on 7/18/08 2:51 PM): Well, I'd start by asking what the rationale is for mutation events at all :) They seem to only solve the very simple cases where all parties that mutate the page cooperate nicely with each other and with the parties that listen to mutation

Re: Widgets and :context

Charles McCathieNevile wrote: On Thu, 17 Jul 2008 20:31:13 +0200, Andrew Fedoniouk <[EMAIL PROTECTED]> wrote: That is what I thought: widgets if used as components on some page behave as a micro documents - fragments of the DOM with local style systems rooted to the widget. But it seems th

Re: [D3E] Possible Changes to Mutation Events

Kartikaya Gupta wrote: On Thu, 17 Jul 2008 17:51:42 -0700, Jonas Sicking <[EMAIL PROTECTED]> wrote: * Add a DOMDescendantRemovedFromDocument event which is fired on a node when the node is in a document, but any of nodes the descendants is removed from the document. The event is fired aft

Re: [D3E] Possible Changes to Mutation Events

Doug Schepers wrote: Hi, Jonas- Thanks for this modified proposal. I want to hear back from those who've already commented as to their disposition, and to solicit comments from other known implementors (e.g., gtk, BitFlash, Opera, JSR), but I think your proposal is reasonable, and well det

Re: Proposal for an extension XMLHttpRequest to allow sending files

On Thu, Jul 17, 2008 at 4:06 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > On Jul 17, 2008, at 3:53 PM, Aaron Boodman wrote: >> I have two minor concerns with this proposal, both in the cases where >> it differs from Gears: >> >> 1. Combining the concepts of 'large chunk of binary data' and '

Re: #webapps is now logged

On Fri, 18 Jul 2008 13:30:21 +0200, Krijn Hoetmer <[EMAIL PROTECTED]> wrote: It is my understanding that Krijn implemented some type of "[off]" functionality. Krijn - would you please provide a short summary regarding that function (or a pointer to such information)? If you say "And the

Re: [D3E] Possible Changes to Mutation Events

On Thu, 17 Jul 2008 17:51:42 -0700, Jonas Sicking <[EMAIL PROTECTED]> wrote: > > As for when the events fire (note that this is just clarifications of > the spec, not changes to it): > For events that fire after the mutation takes place I propose that we > add a concept of a "compound operation

Re: #webapps is now logged

Arthur Barstow wrote: It is my understanding that Krijn implemented some type of "[off]" functionality. Krijn - would you please provide a short summary regarding that function (or a pointer to such information)? It works like this: This is a message with [off] some hidden content That app

Re: #webapps is now logged

It is my understanding that Krijn implemented some type of "[off]" functionality. Krijn - would you please provide a short summary regarding that function (or a pointer to such information)? If you say "And the [off] is some secret info." you'll get http://krijnhoetmer.nl/irc-logs/webapps

#webapps is now logged

Hi All, Thanks to Krijn, the #webapps channel is now logged and the log can be accessed at the same place a couple of other W3C channels (e.g. #html-wg) are logged: It is my understanding that Krijn implemented some type of "[off]" functionality. Krij

Re: Widgets and :context

On Thu, 17 Jul 2008 20:31:13 +0200, Andrew Fedoniouk <[EMAIL PROTECTED]> wrote: That is what I thought: widgets if used as components on some page behave as a micro documents - fragments of the DOM with local style systems rooted to the widget. But it seems that this is not the case - tha

Re: Opera's Proposal for :context Selector

-www-style +public-webapps Andrew Fedoniouk wrote: Lachlan Hunt wrote: Andrew Fedoniouk wrote: Bert Bos wrote: (It seems to me you shouldn't need it at all. The problem seems to be that x.querySelector(":root") doesn't return x. That looks strange to me: you pass a tree and a pattern, and y