On 03/05/2013 21:05 , Florian Bösch wrote:
It can be implemented by a JS library, but the three reasons to let the
browser provide it are Convenience, speed and integration.
Also, one of the reasons we compress things is because they're big.*
Unpacking in JS is likely to mean unpacking to
The main reason to use an archive (other than the space-savings) for me is
to be able to transfer tens of thousands of small items that go into
producing WebGL applications of non trivial scope.
On Mon, May 6, 2013 at 1:27 PM, Robin Berjon ro...@w3.org wrote:
On 03/05/2013 21:05 , Florian
On Mon, May 6, 2013 at 6:27 AM, Robin Berjon ro...@w3.org wrote:
Another question to take into account here is whether this should only be
about zip. One of the limitations of zip archives is that they aren't
streamable. Without boiling the ocean, adding support for a streamable
format (which
Two of the tests in
http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-content-type-string.htm
fails in Firefox just because there is a space before the word charset.
Aren't both text/html;charset=windows-1252 and text/html;
charset=windows-1252 valid MIME types? Should we
I second that. Thanks Florian.
On 05/03/2013 02:52 PM, Florian Bösch wrote:
I'm interested a JS API that does the following:
Unpacking:
- Receive an archive from a Dataurl, Blob, URL object, File (as in
filesystem API) or Arraybuffer
- List its content and metadata
- Unpack members to
Aren't both text/html;charset=windows-1252 and text/html;
charset=windows-1252 valid MIME types? Should we make the tests a bit more
accepting?
Reading http://www.w3.org/Protocols/rfc1341/4_Content-Type.html it's not
crystal clear if spaces are accepted, although white spaces and space
are
On Mon, May 6, 2013 at 9:31 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
...
The reason the tests test that is because the specification requires
exactly that. If you want to change the tests, you'd first have to
change the specification. (What HTTP says on the matter is not
I had a discussion with Hallvord on IRC about the exact semantics we
want for HTTP authentication in the context of CORS (and in particular
for XMLHttpRequest, though it would also affect e.g. img
crossorigin).
So me and Anne have been going a bit back and forth on IRC, we agree on some
Works for me!
-Original Message-
From: Cameron McCormack [mailto:c...@mcc.id.au]
Sent: Sunday, May 05, 2013 12:39 AM
To: Travis Leithead
Cc: public-webapps
Subject: Re: [WebIDL] Bugs - which are for 1.0 and which are for Second Edition?
Travis Leithead wrote:
There's 50 some-odd bugs
On Mon, May 6, 2013 at 10:45 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
I had a discussion with Hallvord on IRC about the exact semantics we
want for HTTP authentication in the context of CORS (and in particular
for XMLHttpRequest, though it would also affect e.g. img
On Mon, May 6, 2013 at 5:03 AM, Glenn Maynard gl...@zewt.org wrote:
On Mon, May 6, 2013 at 6:27 AM, Robin Berjon ro...@w3.org wrote:
Another question to take into account here is whether this should only be
about zip. One of the limitations of zip archives is that they aren't
streamable.
Here I don't agree anymore. If I want to retrieve a HTTP auth-protected
resource
with XHR from a CORS-enabled server, the natural thing to do seems to try to
pass
in the user name and password in the XHR open() call. If the script author
supplied
user/pass and the server says 401 on a
On Mon, May 6, 2013 at 4:27 AM, Robin Berjon ro...@w3.org wrote:
On 03/05/2013 21:05 , Florian Bösch wrote:
It can be implemented by a JS library, but the three reasons to let the
browser provide it are Convenience, speed and integration.
Also, one of the reasons we compress things is
On Mon, May 6, 2013 at 7:42 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, May 6, 2013 at 4:27 AM, Robin Berjon ro...@w3.org wrote:
On 03/05/2013 21:05 , Florian Bösch wrote:
It can be implemented by a JS library, but the three reasons to let the
browser provide it are Convenience, speed
Here I don't agree anymore. If I want to retrieve a HTTP auth-protected
resource
with XHR from a CORS-enabled server, the natural thing to do seems to try
to pass
in the user name and password in the XHR open() call. If the script author
supplied
user/pass and the server says 401
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21945
Bug ID: 21945
Summary: Does responseXML ever return an XMLDocument
Classification: Unclassified
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Linux
Hey Anne,
I don't quite get why you're saying HTTP is irrelevant.
As an example, regarding the content-type *request *header, the XHR spec
clearly states:
If a Content-Type header is in author request
headershttp://www.w3.org/TR/XMLHttpRequest/#author-request-headers
and
its value is a valid
On 03.05.13 15:18, Jonas Sicking jo...@sicking.cc wrote:
On Fri, May 3, 2013 at 12:12 PM, Paul Bakaus pbak...@zynga.com wrote:
From: Florian Bösch pya...@gmail.com
Date: Fri, 3 May 2013 21:05:17 +0200
To: Jonas Sicking jo...@sicking.cc
Cc: Paul Bakaus pbak...@zynga.com, Anne van Kesteren
On Mon, May 6, 2013 at 1:39 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
(Could we however fix this in CORS so that the WWW-Authenticate header could
be included in a preflight response where applicable?)
Maybe we should wait for actual complaints about XMLHttpRequest + CORS
On Mon, May 6, 2013 at 3:44 PM, Julian Aubourg j...@ubourg.net wrote:
I don't quite get why you're saying HTTP is irrelevant.
For the requirements where the XMLHttpRequest says to put a certain
byte string as a value of a header, that's what the implementation has
to do, and nothing else. We
On Sun, May 5, 2013 at 5:37 PM, Jonas Sicking jo...@sicking.cc wrote:
What we do is that we
1. Resolve the URL against the current base URL
2. Perform some security checks
3. Kick off a network fetch
4. Return
Okay. So that fails for XMLHttpRequest :-( But if we made it part of
resolve that
You made the whole thing a lot clearer to me, thank you :)
It seems strange the spec would require a case-sensitive value for
Content-Type in certain circumstances. Are these deviations from the
case-insensitiveness of the header really necessary ? Are they beneficial
for authors ? It seems to
On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg j...@ubourg.net wrote:
It seems strange the spec would require a case-sensitive value for
Content-Type in certain circumstances. Are these deviations from the
case-insensitiveness of the header really necessary ? Are they beneficial
for authors ?
I hear you, but isn't having a case-sensitive value of Content-Type *in
certain circumstances* triggering the kind of problem you're talking about
(developers to depend on
certain things they really should not depend on) ?
As I see it, the tests in question here are doing something that is wrong
On Mon, May 6, 2013 at 1:11 PM, Eric U er...@google.com wrote:
This came up a few years ago; Gregg Tavares explained in [1] that only
/some/ zipfiles are streamable, and you don't know whether yours are
or not until you've seen the whole file.
Eric
[1]
If we are talking about RFC2617 HTTP Authentication, there are 2 authentication
models:
(1) Basic Authentication model:
Under this circumstance, basically client can send the username:password pair
at the first request, e.g. in the form:
https://username:passw...@www.example.com/path
which
On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, May 5, 2013 at 5:37 PM, Jonas Sicking jo...@sicking.cc wrote:
What we do is that we
1. Resolve the URL against the current base URL
2. Perform some security checks
3. Kick off a network fetch
4. Return
Okay.
On Mon, May 6, 2013 at 5:45 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren ann...@annevk.nl wrote:
Okay. So that fails for XMLHttpRequest :-(
What do you mean? Those are the steps we take for XHR requests too.
So e.g. open() needs to do URL parsing
On Mon, May 6, 2013 at 5:15 PM, Glenn Maynard gl...@zewt.org wrote:
I'm not aware of any optimized inflate implementation in JS to compare
against, and it's a complex algorithm, so nobody is likely to jump forward
to spend a lot of time implementing and heavily optimizing it just to show
how
On Tue, 07 May 2013 01:39:26 +0200, Anne van Kesteren ann...@annevk.nl
wrote:
On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg j...@ubourg.net wrote:
It seems strange the spec would require a case-sensitive value for
Content-Type in certain circumstances. Are these deviations from the
On Mon, May 6, 2013 at 7:57 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, May 6, 2013 at 5:45 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren ann...@annevk.nl
wrote:
Okay. So that fails for XMLHttpRequest :-(
What do you mean? Those
On Mon, May 6, 2013 at 8:01 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, May 6, 2013 at 5:15 PM, Glenn Maynard gl...@zewt.org wrote:
I'm not aware of any optimized inflate implementation in JS to compare
against, and it's a complex algorithm, so nobody is likely to jump
forward
to
Since XHR is the API to facilitate a valid HTTP transaction, IMHO, it should be
fully compliant with HTTP - no more and no less. A valid HTTP request and
response should be interpreted consistently across UA's and devices.
Interoperability is very important across UA's and devices. If the XHR,
On Wed, May 1, 2013 at 5:16 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, May 1, 2013 at 7:01 PM, Eric U er...@google.com wrote:
Hmm...now Glenn points out another problem: if you /never/ load the
image, for whatever reason, you can still leak it. How likely is that
in good code, though?
34 matches
Mail list logo
