Re: XHR content-type rewriting

2011-11-16 Thread Julian Reschke
On 2011-11-17 01:55, Boris Zbarsky wrote: On 11/17/11 2:18 AM, Julian Reschke wrote: - Opera and IE do not rewrite the type; so if the caller sets the wrong charset, this is what is sent to the server Which on the face of it is broken Absolutely. It would be less broken spec-wise if XHR

[Bug 14848] New: HTTP/1.1 101 Switching Protocols Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Accept: nToZIrKj/IYE0NjsLns7R+Msfcg=

2011-11-16 Thread bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14848 Summary: HTTP/1.1 101 Switching Protocols Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Accept: nToZIrKj/IYE0NjsLns7R+Msfcg= Product: WebAppsWG Version: unspecified

[Bug 14847] New: HTTP/1.1 101 Switching Protocols Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Accept: nToZIrKj/IYE0NjsLns7R+Msfcg=

2011-11-16 Thread bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14847 Summary: HTTP/1.1 101 Switching Protocols Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Accept: nToZIrKj/IYE0NjsLns7R+Msfcg= Product: WebAppsWG Version: unspecified

Re: XHR content-type rewriting

2011-11-16 Thread Boris Zbarsky
On 11/17/11 2:18 AM, Julian Reschke wrote: - Opera and IE do not rewrite the type; so if the caller sets the wrong charset, this is what is sent to the server Which on the face of it is broken - Finally, only Firefox attempts to preserve the casing of the charset param - this may indicate

Re: [XHR2] Disable new response types for sync XHR in Window context

2011-11-16 Thread Matt Shulman
On Wed, Nov 16, 2011 at 8:20 AM, Glenn Maynard wrote: > On Wed, Nov 16, 2011 at 11:10 AM, Matt Shulman wrote: >> >> I sometimes like to write code in the window context (where debugging >> support is much better) before moving it to a web worker, so it would >> be awkward if the sync options diff

Re: [XHR2] Disable new response types for sync XHR in Window context

2011-11-16 Thread Glenn Maynard
On Wed, Nov 16, 2011 at 11:10 AM, Matt Shulman wrote: > I sometimes like to write code in the window context (where debugging > support is much better) before moving it to a web worker, so it would > be awkward if the sync options differed on xhr between the two. > (Analogous to this - I remember

Re: [XHR2] Disable new response types for sync XHR in Window context

2011-11-16 Thread Matt Shulman
I sometimes like to write code in the window context (where debugging support is much better) before moving it to a web worker, so it would be awkward if the sync options differed on xhr between the two. (Analogous to this - I remember once i was trying to use the new FileSystemSync API and during

Re: [XHR2] Disable new response types for sync XHR in Window context

2011-11-16 Thread Anne van Kesteren
On Tue, 15 Nov 2011 20:33:38 +0100, Jonas Sicking wrote: So if I understand the proposal correctly: After .open has been called with async=false: * setting .responseType to anything other than "" throws InvalidAccessError * setting .wirthCredentials to true throws InvalidAccessError Additio

[Bug 14842] New: Update createContextualFragment if detached flag is removed

2011-11-16 Thread bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14842 Summary: Update createContextualFragment if detached flag is removed Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Se

XHR content-type rewriting

2011-11-16 Thread Julian Reschke
Hi, while trying to fix a bug I discovered a weird workaround in Mozilla (). The summary is: 1) when sending text using send(""), all browsers encode in UTF-8 2) the caller may have set the content-type header field before 3) if this was

[XHR2] HTML in XHR implementation feedback

2011-11-16 Thread Henri Sivonen
I landed support for HTML parsing in XHR in Gecko today. It has not yet propagated to the Nightly channel. Here's how it behaves: * Contrary to the spec, for response types other than "" and "document", character encoding determination for text/html happens the same way as for unknown types. *

Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter

2011-11-16 Thread Dave Raggett
On 15/11/11 20:46, Paul Kinlan wrote: This is the way that I have implemented it in test apps. It is the handler app that will show the progress information. I have not had a case yet where the client app needs or is concerned about the progress of the action that is being handled, other than