Re: [CORS] Access-Control-Request-Method

On Wed, Dec 21, 2011 at 11:37 PM, Boris Zbarsky wrote: > On 12/21/11 11:28 PM, Jarred Nicholls wrote: > >> I'll try this again... >> >> The spec makes it very succinct in its preflight request steps that >> Access-Control-Request-Method should be sent, always. However in WebKit >> and Firefox I'

Re: [CORS] Access-Control-Request-Method

On 12/21/11 11:28 PM, Jarred Nicholls wrote: I'll try this again... The spec makes it very succinct in its preflight request steps that Access-Control-Request-Method should be sent, always. However in WebKit and Firefox I'm observing this header only being sent when there are "author request he

[CORS] Access-Control-Request-Method

I'll try this again... The spec makes it very succinct in its preflight request steps that Access-Control-Request-Method should be sent, always. However in WebKit and Firefox I'm observing this header only being sent when there are "author request headers" being sent in Access-Control-Request-Hea

[CORS] Access-Control-Request-Method was Re: [CORS] Allow-Access-Request-Method

On Wed, Dec 21, 2011 at 11:09 PM, Boris Zbarsky wrote: > On 12/21/11 11:04 PM, Jarred Nicholls wrote: > >> The spec makes it very succinct in its preflight request steps that >> Allow-Access-Request-Method should be sent, always. >> > > There is no such thing. What header did you actually mean?

Re: [CORS] Allow-Access-Request-Method

On 12/21/11 11:04 PM, Jarred Nicholls wrote: The spec makes it very succinct in its preflight request steps that Allow-Access-Request-Method should be sent, always. There is no such thing. What header did you actually mean? -Boris

[CORS] Allow-Access-Request-Method

The spec makes it very succinct in its preflight request steps that Allow-Access-Request-Method should be sent, always. However in WebKit and Firefox I'm observing this header only being sent when there are "author request headers" being sent in Allow-Access-Request-Headers. Is the spec not clear

Re: [cors] Should browsers send non-user-controllable headers in Access-Control-Request-Headers?

On Wed, Dec 21, 2011 at 9:16 PM, Benson Margulies wrote: > Chrome sends: > > Access-Control-Request-Headers:Origin, Content-Type, Accept > > Is that just wrong? > > The spec clearly says: "author request headers: A list of headers set by authors for the request. Empty, unless explicitly set." So

Heads up: RDFa 1.1 headed into Last Call in January 2012

bcc: HTML WG, HTML Data Task Force, Web Apps WG, RDF WG, W3C TAG, SWCG, SVG WG, and PFWG This e-mail is to notify the liaison groups that are listed in the RDF Web Apps Working Group charter that the RDF Web Apps WG will be taking the RDFa 1.1 specs into what it hopes to be their final Last Call

Re: [cors] The case of Http Headers in Access-Control-Request-Headers

On 12/21/11 9:43 PM, Benson Margulies wrote: I just made a small discovery; Chrome 16 sends, e.g. Access-Control-Request-Headers: Content-Type Firefox 8.0 sends, contrastively: Access-Control-Request-Headers: content-type Given the requirement for case-sensitive comparison in the spec

[cors] The case of Http Headers in Access-Control-Request-Headers

I just made a small discovery; Chrome 16 sends, e.g. Access-Control-Request-Headers: Content-Type Firefox 8.0 sends, contrastively: Access-Control-Request-Headers: content-type Given the requirement for case-sensitive comparison in the spec, this to me suggests that one of them is wrong. W

[cors] Should browsers send non-user-controllable headers in Access-Control-Request-Headers?

Chrome sends: Access-Control-Request-Headers:Origin, Content-Type, Accept Is that just wrong?

[Bug 15307] New: [XHR] (editorial) the Extensibilty section suggest method prefixing like FooBar() instead of fooBar()

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15307 Summary: [XHR] (editorial) the Extensibilty section suggest method prefixing like FooBar() instead of fooBar() Product: WebAppsWG Version: unspecified Platform: PC OS/Version

[Bug 15306] New: [XHR] (editorial) Mark the event summary section as non-normative.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15306 Summary: [XHR] (editorial) Mark the event summary section as non-normative. Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW

[Bug 15305] New: [XHR] (editorial) Missing "When set: " in the non-nomative box of the responseType attribute.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15305 Summary: [XHR] (editorial) Missing "When set: " in the non-nomative box of the responseType attribute. Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All

Re: [XHR2] timeout

On Wed, Dec 21, 2011 at 3:54 PM, Glenn Maynard wrote: > On Wed, Dec 21, 2011 at 2:55 PM, Jarred Nicholls wrote: > >> On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls >>> wrote: >>> 1. Clean code, which is better for authors and the web platform. To achieve the same result

Re: [XHR2] timeout

On Wed, Dec 21, 2011 at 2:55 PM, Jarred Nicholls wrote: > On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls >> wrote: >> >>> >>>1. Clean code, which is better for authors and the web platform. To >>>achieve the same results as a native dataTimeout, your snippet would need >>>to be

Re: [XHR2] timeout

(11/12/21 23:47), Anne van Kesteren wrote: > On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls > wrote: >> 1. The spec says the timeout should fire after the specified number of >> milliseconds has elapsed since the start of the request. I presume >> this means literally that, with no bearing o

Re: [XHR2] timeout

On Wed, Dec 21, 2011 at 2:26 PM, Glenn Maynard wrote: > On Wed, Dec 21, 2011 at 2:25 PM, Jarred Nicholls wrote: > >> You sound really self-conflicted based on how you started your message >> vs. how you ended it. >> > > Please be less vague. > My apologies. See below. > What if a UA suspends

Re: [XHR2] timeout

On Wed, Dec 21, 2011 at 2:15 PM, Olli Pettay wrote: > On 12/21/2011 08:59 PM, Jarred Nicholls wrote: > >> On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay > > wrote: >> >>On 12/21/2011 05:59 PM, Jarred Nicholls wrote: >> >>On Wed, Dec 21, 2011 at 10:47 AM

Re: [XHR2] timeout

On Wed, Dec 21, 2011 at 2:25 PM, Jarred Nicholls wrote: > You sound really self-conflicted based on how you started your message vs. > how you ended it. > Please be less vague. -- Glenn Maynard

Re: [XHR2] timeout

On Wed, Dec 21, 2011 at 2:20 PM, Glenn Maynard wrote: > On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay wrote: > >> xhr.onprogress = function() { >> this.timeout += 250; >> } >> > > What if a UA suspends scripts in background pages (eg. to save battery), > but allows XHR requests to continue? This

Re: [XHR2] timeout

On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay wrote: > xhr.onprogress = function() { > this.timeout += 250; > } > What if a UA suspends scripts in background pages (eg. to save battery), but allows XHR requests to continue? This would time out as soon as that happened. This particular snippet s

Re: [XHR2] timeout

On 12/21/2011 08:59 PM, Jarred Nicholls wrote: On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay mailto:olli.pet...@helsinki.fi>> wrote: On 12/21/2011 05:59 PM, Jarred Nicholls wrote: On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren mailto:ann...@opera.com>

Re: [cors] Simple Header question

On Wed, 21 Dec 2011 19:24:19 +0100, Benson Margulies wrote: There are a number of standard headers that aren't listed as simple headers but which I am suspecting are allowed in any case via some other principle: Accept-Charset Accept-Encoding Connection Host Referer User-Agent Cookie Is this

Re: [XHR2] timeout

On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay wrote: > On 12/21/2011 05:59 PM, Jarred Nicholls wrote: > >> On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren > > wrote: >> >>On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls >>mailto:jar...@webkit.org>> wrote: >>

Re: [XHR2] timeout

On 12/21/2011 05:59 PM, Jarred Nicholls wrote: On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren mailto:ann...@opera.com>> wrote: On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls mailto:jar...@webkit.org>> wrote: 1. The spec says the timeout should fire after the specified

[cors] Simple Header question

There are a number of standard headers that aren't listed as simple headers but which I am suspecting are allowed in any case via some other principle: Accept-Charset Accept-Encoding Connection Host Referer User-Agent Cookie Is this true or some or all of these? If so, how was I supposed to figur

Re: Bug in file system Api specification

Bronislav: Thanks for the tip; it's already fixed in the latest editor's draft, so the fix will get published the next time the document is. See the latest at http://dev.w3.org/2009/dap/file-system/file-dir-sys.html. Eric On Wed, Dec 21, 2011 at 12:21 AM, Bronislav Klučka wrote: >

Re: [webcomponents]: First draft of the Shadow DOM Specification

On Tue, Dec 20, 2011 at 5:38 PM, Brian Kardell wrote: > Yes, I had almost the same thought, though why not just require a prefix? > > I also think some examples actually showing some handling of events and use > of css would be really helpful here... The upper boundary for css vs > inheritance I t

Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

Hi Art, the pessimistic XMLSECPAG chair told you that it wouldn't resolve within days. But I hope to have a clear view and plan by the end of January. Executing that plan may take some time. Plan is to resolve until end of March, if everything goes well. Well meaning a decision of the PAG and

Re: [XHR2] timeout

On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren wrote: > On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls > wrote: > >> 1. The spec says the timeout should fire after the specified number of >> >> milliseconds has elapsed since the start of the request. I presume this >> means literally t

Re: [XHR2] timeout

On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls wrote: 1. The spec says the timeout should fire after the specified number of milliseconds has elapsed since the start of the request. I presume this means literally that, with no bearing on whether or not data is coming over the wire?

Re: [XHR2] timeout

Are any user agents other than IE8+ currently implementing or have implemented XHR2 timeout? https://bugs.webkit.org/show_bug.cgi?id=74802 I have a couple of things I wanted to question, which may or may not result in clarification in the spec. 1. The spec says the timeout should fire after

Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

TLR, FH, XMLSecWG, On 12/21/11 6:03 AM, ext Marcos Caceres wrote: Lets go back an look at the options we have to divorce Widgets/XML Dig Sig from Elliptic Curve: 1. Remove ECC from XML Dig Sig (in my opinion, "the right thing to do"™): pros: - frees both XML Dig Sig and Widgets

Re: Bug Tracking for the File* specs [Was: Re: Bug in file system Api specification]

Hi Arthur, I do not "need" them :) that's mainly for editors to keep track in one place :) I just suggest this bug to be fixed and it's silly to spam whole forum because of it :) (I do not have access to file a bug in this W3C tracking tool) Brona On 21.12.2011 13:05, Arthur Barstow wrote:

Bug Tracking for the File* specs [Was: Re: Bug in file system Api specification]

Hi Brona, For mostly historical reasons, WebApps' File* specs still use Tracker rather than Bugzilla (and IIRC, Arun also uses the list archive as well as the spec itself to track issues for the File API spec): http://www.w3.org/2008/webapps/track/products For consistency, it would be good

Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

As fun as this is, all this mud slinging is really not getting us anywhere useful. Lets go back an look at the options we have to divorce Widgets/XML Dig Sig from Elliptic Curve: 1. Remove ECC from XML Dig Sig (in my opinion, "the right thing to do"™): pros: - frees both XM

Re: CfC: add Quota API to WebApps' charter; deadline December 20

Hi, (Sorry for my slow response, I'm in a half-vacation status) On Sun, Dec 18, 2011 at 12:19 AM, Charles McCathieNevile wrote: > On Fri, 16 Dec 2011 10:10:45 +0100, Kinuko Yasuda > wrote: > > On Thu, Dec 15, 2011 at 9:19 PM, Arthur Barstow > >wrote: >> >> Hi Kinuko, All, >>> >>> Besides the

Bug in file system Api specification

Hi http://www.w3.org/TR/file-system-api/#widl-FileEntry-file says that successCallback is "A callback that is called with the newFileWriter." there should be "A callback that is called with the File" BTW was trying to file that bug myself, but I could not find suitable component in WebAppsWG

[Bug 15293] New: HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://www.cnodejs.org WebSocket-Location: ws://www.cnodejs.org:8088/echo

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15293 Summary: HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://www.cnodejs.org WebSocket-Location: ws://www.cnodejs.org:8