Is new XHR spec going to make gzip mandatory for its underlying HTTP?
On Tue, Jul 26, 2011 at 06:05, Aryeh Gregor simetrical+...@gmail.comwrote:
From the discussion here, it sounds like there are problems with
WebSockets compression as currently defined. If that's the case, it
might be
On Wed, 27 Jul 2011 03:35:03 -0700, Takeshi Yoshino tyosh...@google.com
wrote:
Is new XHR spec going to make gzip mandatory for its underlying HTTP?
I do not think that analogy makes sense. The WebSocket protocol can only
be used through the WebSocket API, HTTP is prevalent in more places.
On Thu, Jul 28, 2011 at 00:06, Anne van Kesteren ann...@opera.com wrote:
On Wed, 27 Jul 2011 03:35:03 -0700, Takeshi Yoshino tyosh...@google.com
wrote:
Is new XHR spec going to make gzip mandatory for its underlying HTTP?
I do not think that analogy makes sense. The WebSocket protocol can
Hi guys,
I'm the maintainer of CORS Filter, a small library for retrofitting
Java web apps with CORS support.
A developer who is using the library reported that the library was
unexpectedly denying CORS requests from version 13 (still in beta)
Google Chrome browsers. He contacted Google support
On Wed, Jul 27, 2011 at 9:32 AM, Vladimir Dzhuvinov
vladi...@dzhuvinov.com wrote:
Hi guys,
I'm the maintainer of CORS Filter, a small library for retrofitting
Java web apps with CORS support.
A developer who is using the library reported that the library was
unexpectedly denying CORS
On Wed, 27 Jul 2011 08:49:57 -0700, Takeshi Yoshino tyosh...@google.com
wrote:
What do you mean by more places?
XMLHttpRequest is not the sole API for HTTP, there's also a, form,
etc. So indicating what parts of the HTTP protocol are mandatory for
browsers is not really in scope for
Le 12/07/2011 20:00, Thierry MICHEL a écrit :
Chairs and Team Contact,
(1) This is a 2nd Last Call Working Draft Transition Announcement for
the following Recommendation Track specification:
(2) Document Title and URI
* API for Media Resources 1.0
On Thu, Jul 28, 2011 at 02:03, Anne van Kesteren ann...@opera.com wrote:
On Wed, 27 Jul 2011 08:49:57 -0700, Takeshi Yoshino tyosh...@google.com
wrote:
What do you mean by more places?
XMLHttpRequest is not the sole API for HTTP, there's also a, form, etc.
So indicating what parts of the
On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com
wrote:
So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5//.
HTML5 is mostly transport-layer agnostic.
I am not sure why we are going through this theoretical side-quest on
where we should state what
We are talking about it at IETF81 this week.
That said, I think either way browsers should not require deflate-stream. I
am hoping we can make forward progress on deflate-application-data (
http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01).
If we can get that through
On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote:
We are talking about it at IETF81 this week.
That said, I think either way browsers should not require deflate-stream. I
am hoping we can make forward progress on deflate-application-data (
On 27 July 2011 17:44, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jul 27, 2011 at 9:32 AM, Vladimir Dzhuvinov
vladi...@dzhuvinov.com wrote:
Hi guys,
I'm the maintainer of CORS Filter, a small library for retrofitting
Java web apps with CORS support.
A developer who is using the library
On Wed, 27 Jul 2011 14:19:26 -0700, Vladimir Dzhuvinov
vladi...@dzhuvinov.com wrote:
I carefully examined the bits of the CORS spec (edition
http://www.w3.org/TR/2010/WD-cors-20100727/ ) relevant to the
Access-Control-Request-Header.
Could you please review
I don't think we want to forbid any extensions. The whole point of
extensions is to allow people to do something that doesn't necessarily have
consensus by a broad enough group to be in the base protocol. That said, I
think a lot of people would be happier if deflate-stream were an independent
On Wed, Jul 27, 2011 at 3:14 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote:
I don't think we want to forbid any extensions.
At the protocol level, sure. At the API level we have to pick which
functionality user agents are required to support and which they are
required not to support, having
I agree we shouldn't require deflate-stream it in the API. I don't agree the
API should specify an exact set of extensions, as that would prevent any
future versions/developments. A minimum baseline would be reasonable though,
once we have that minimum baseline in place (e.g. a stable set of
On Wed, 27 Jul 2011 15:31:28 -0700, Ian Fette (イアンフェッティ)
ife...@google.com wrote:
I agree we shouldn't require deflate-stream it in the API. I don't agree
the API should specify an exact set of extensions, as that would prevent
any
future versions/developments. A minimum baseline would be
On Wed, 27 Jul 2011, Ian Fette (�~B��~B��~C��~C~U�~B��~C~C�~C~F�~B�) wrote:
I agree we shouldn't require deflate-stream it in the API. I don't agree
the API should specify an exact set of extensions, as that would prevent
any future versions/developments. A minimum baseline would be
On 27 July 2011 20:35, Takeshi Yoshino tyosh...@google.com wrote:
(a) it's not acceptable to make support (== request) of good-compression
optional
I understand the desire to make good compression universal, but I'm
not sure that making it a required part of the specification is the
way to go.
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Anne van Kesteren
Sent: Friday, July 22, 2011 8:09 AM
To: WebApps WG
Subject: From-Origin FPWD
Hi,
The WebApps WG published the From-Origin header proposal as FPWD:
On Mon, Jul 25, 2011 at 3:52 PM, Gabriel Montenegro
gabriel.montene...@microsoft.com wrote:
Thanks Adam,
By discussed on some mailing list, do you mean a *W3C* mailing list?
A quick search turned up this message:
But I'm totally fine with punting on this for the future and just
disallowing
I'm still not convinced that implementing this as a feature of the User Agent
benefits the user or is the most appropriate technology for addressing the
problem statements in the specification.
What are the use cases where a user is better off if their browser obeys
From-Origin than if it does
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13162
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|NEW |RESOLVED
23 matches
Mail list logo
