Re: ZIP archive API?

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 memo

Re: ZIP archive API?

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 wrote: > On 03/05/2013 21:05 , Florian Bösch wrote: > >

Re: ZIP archive API?

On Mon, May 6, 2013 at 6:27 AM, Robin Berjon 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 I don't

[XHR] test nitpicks: MIME type / charset requirements

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 w

Re: ZIP archive API?

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 member

Re: [XHR] test nitpicks: MIME type / charset requirements

> 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" a

Re: [XHR] test nitpicks: MIME type / charset requirements

On Mon, May 6, 2013 at 9:31 AM, Hallvord Reiar Michaelsen Steen 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 relevant.) -- http:

Re: Fetch: HTTP authentication and CORS

> 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. crossorigin>). So me and Anne have been going a bit back and forth on IRC, we agree on some stu

RE: [WebIDL] Bugs - which are for 1.0 and which are for Second Edition?

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 u

Re: Fetch: HTTP authentication and CORS

On Mon, May 6, 2013 at 10:45 AM, Hallvord Reiar Michaelsen Steen 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. > crossorigin>). > > So

Re: ZIP archive API?

On Mon, May 6, 2013 at 5:03 AM, Glenn Maynard wrote: > On Mon, May 6, 2013 at 6:27 AM, Robin Berjon 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 oc

Re: Re: Fetch: HTTP authentication and CORS

>> 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 sa

Re: ZIP archive API?

On Mon, May 6, 2013 at 4:27 AM, Robin Berjon 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 because th

Re: ZIP archive API?

On Mon, May 6, 2013 at 7:42 PM, Jonas Sicking wrote: > On Mon, May 6, 2013 at 4:27 AM, Robin Berjon 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. >

Re: Re: Re: Fetch: HTTP authentication and CORS

> >> 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

[Bug 21945] New: Does responseXML ever return an XMLDocument

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

Re: [XHR] test nitpicks: MIME type / charset requirements

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 headers and > its value is a valid

Re: ZIP archive API?

On 03.05.13 15:18, "Jonas Sicking" wrote: >On Fri, May 3, 2013 at 12:12 PM, Paul Bakaus wrote: >> >> >> From: Florian Bösch >> Date: Fri, 3 May 2013 21:05:17 +0200 >> To: Jonas Sicking >> Cc: Paul Bakaus , Anne van Kesteren >>, >> Webapps WG , Charles McCathie Nevile >> , Andrea Marchesini

Re: Re: Re: Fetch: HTTP authentication and CORS

On Mon, May 6, 2013 at 1:39 PM, Hallvord Reiar Michaelsen Steen 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 lacking integrated

Re: [XHR] test nitpicks: MIME type / charset requirements

On Mon, May 6, 2013 at 3:44 PM, Julian Aubourg 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 could make the XML

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Sun, May 5, 2013 at 5:37 PM, Jonas Sicking 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 could wo

Re: [XHR] test nitpicks: MIME type / charset requirements

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 me

Re: [XHR] test nitpicks: MIME type / charset requirements

On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg 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 ? It seems to

Re: [XHR] test nitpicks: MIME type / charset requirements

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 "wron

Re: ZIP archive API?

On Mon, May 6, 2013 at 1:11 PM, Eric U 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] > http://lists.w3.org/Archives/Public/publ

RE: Re: Fetch: HTTP authentication and CORS

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 whic

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren wrote: > On Sun, May 5, 2013 at 5:37 PM, Jonas Sicking 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

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Mon, May 6, 2013 at 5:45 PM, Jonas Sicking wrote: > On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren 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 (per XHR spec), send() woul

Re: ZIP archive API?

On Mon, May 6, 2013 at 5:15 PM, Glenn Maynard 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 slow it is.

Re: [XHR] test nitpicks: MIME type / charset requirements

On Tue, 07 May 2013 01:39:26 +0200, Anne van Kesteren wrote: On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg 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 real

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Mon, May 6, 2013 at 7:57 PM, Anne van Kesteren wrote: > On Mon, May 6, 2013 at 5:45 PM, Jonas Sicking wrote: > > On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren > wrote: > >> Okay. So that fails for XMLHttpRequest :-( > > > > What do you mean? Those are the steps we take for XHR requests t

Re: ZIP archive API?

On Mon, May 6, 2013 at 8:01 PM, Jonas Sicking wrote: > On Mon, May 6, 2013 at 5:15 PM, Glenn Maynard 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 imple

RE: [XHR] test nitpicks: MIME type / charset requirements

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, e

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Wed, May 1, 2013 at 5:16 PM, Glenn Maynard wrote: > On Wed, May 1, 2013 at 7:01 PM, Eric U 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? And is it worse than t

Re: ZIP archive API?

On Mon, May 6, 2013 at 6:36 PM, Glenn Maynard wrote: > On Mon, May 6, 2013 at 8:01 PM, Jonas Sicking wrote: >> >> On Mon, May 6, 2013 at 5:15 PM, Glenn Maynard wrote: >> > I'm not aware of any optimized inflate implementation in JS to compare >> > against, and it's a complex algorithm, so nobody

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Mon, May 6, 2013 at 5:57 PM, Anne van Kesteren wrote: > On Mon, May 6, 2013 at 5:45 PM, Jonas Sicking wrote: >> On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren wrote: >>> Okay. So that fails for XMLHttpRequest :-( >> >> What do you mean? Those are the steps we take for XHR requests too. > >