if we are not coming up with a better plan.
Best regards,
Jungkee
-Original Message-
From: Arthur Barstow [mailto:art.bars...@gmail.com]
Sent: Friday, August 07, 2015 8:37 PM
To: Hallvord Reiar Michaelsen Steen; Jungkee Song; Julian Aubourg
Cc: WebApps WG
Subject: Re: W3C's
But Content-Length is not the same as the length of the string containing
the Data URL.
On 20 September 2013 03:39, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/19/13 9:31 PM, Anne van Kesteren wrote:
Doesn't that depend on how you end up storing it whether getting that
information is fast
Sure, what I actually meant is that you'd need to somehow pre-parse the
data URL to extract the exact length before storage. Dunno how
desirable/desired/common this is.
On 20 September 2013 04:58, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/19/13 10:51 PM, Julian Aubourg wrote:
But Content
-Length.
Do I make sense?
On 20 September 2013 05:24, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Sep 19, 2013 at 8:10 PM, Julian Aubourg j...@ubourg.net wrote:
Sure, what I actually meant is that you'd need to somehow pre-parse the
data
URL to extract the exact length before storage
, Julian Aubourg wrote:
We need to check the encoding
You mean the base64 or lack thereof?
we need to make sure we
know how to determine the actual length for this encoding
For base64 you do. Otherwise, it's a malformed data URI.
we need a way
to not store length if we dunno
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
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
to me they promote bad practice (case-sensitive
testing of Content-Type).
On 7 May 2013 01:20, Anne van Kesteren ann...@annevk.nl wrote:
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 same code will fail if, say, the server sets a
Content-Type. Shouldn't we protect authors from such inconsistencies ?
On 7 May 2013 01:39, 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
Hi Robin and sorry if this has been asked and/or answered elsewhere (I've
been ultra-busy elsewhere as of late),
I suppose that there is a hook in place on the github repo so that
manifests are auto-magically re-generated whenever a new test is added to a
main directory? Or is this still manual?
can i ask, how do you use the abort event handler?
and error event handler
In jQuery 1.x, we don't even use onsuccess, onerror and onabort. Reason
being onreadystatechange is the only cross-browser means to handle
XMLHttpRequest when you have to support old IEs (and we try and avoid
having
I have the same questions as Jungkee. What is it you want to remove
exactly? Why do you think the distinction between an user-initiated abort
and a network error is irrelevant? If I am to believe jQuery's bug tracker,
our users want and need the distinction.
On 25 February 2013 07:49, Jungkee
missing the point again?
On 25 February 2013 10:08, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Feb 25, 2013 at 8:20 AM, Julian Aubourg j...@ubourg.net wrote:
I have the same questions as Jungkee. What is it you want to remove
exactly?
Why do you think the distinction between an user
I agree with Glenn that these user cancellations would be better notified
as errors rather than aborts. Key here is to make it possible for authors
to know what's going on and onabort seems quite confusing.
Side note: IE not cancelling requests is a real pain, we have to abort
manually on unload
I'd personally be in favour of an optional parameter that would ask the
browser to keep on with the request even after the page has been unloaded
(which would be the only solution not to block unloading while ensuring
data is delivered even for asynchronous requests).
I'm not sure how feasibly
I love the idea of moving to github.
The one-repo idea, while much simpler from a maintenance point of view,
could easily be a burden on users that subscribe to it. Even more so for
people who can merge PRs (and thus will receive an email for a PR
initiatedfor any spec).
Not saying it is
acknowledging the WHATWG source? Where in the spec?
How? With what kind of wording?
-- Julian Aubourg
On 23 November 2012 17:36, Adam Barth w...@adambarth.com wrote:
On Fri, Nov 23, 2012 at 7:57 AM, Glenn Adams gl...@skynav.com wrote:
On Fri, Nov 23, 2012 at 12:09 AM, Adam Barth w
I tend to agree with Boris on this one.
Couldn't we simply state in the spec that browsers must add the User-Agent
header to the Vary list, all the time? That would instantly solve the
attack-from-the-cache problem, right? No need to sanitize the data, no need
to negotiate anything between both
The point is that a browser can act as if every single server response
included Vary: User-Agent. And perhaps should. Intermediary caches
_certainly_ should.
Yes, that was my point. Do as if User-Agent was part of the Vary response
header.
Hi all,
My name is Julian Aubourg and I'm one of the new co-editors of the XHR spec
(together with Jungkee Song from Samsung and Hallvord R. M. Steen from
Opera).
I'm a member of jQuery Core and rewrote the lib's ajax module and
implemented $.Deferred (and now $.Callbacks). I like everything
, I'd love to be convinced that the change is without
consequences, but the more I think about it, the less likely it seems.
-- Forwarded message --
From: Julian Aubourg j...@ubourg.net
Date: 11 October 2012 14:47
Subject: Re: [XHR] Open issue: allow setting User-Agent?
To: Hallvord R
I personally have contacted hundreds of sites for these types of issues
over the past few years. We've done the education, outreach, evangelism,
etc. Success rates are very low, the majority are simply ignored.
I'm sorry to hear that. I really am. Still trying to have people stop
browser
the hacker's POW or the backend POW)
but I'm just being careful and trying to see if there is potential for
abuse.
On 11 October 2012 16:22, Glenn Maynard gl...@zewt.org wrote:
On Thu, Oct 11, 2012 at 8:09 AM, Julian Aubourg j...@ubourg.net wrote:
I still don't fully understand the scenario(s) you
To me the biggest abomination of all is the XMLHttpRequest object:
- the spec is probably one of the most complex I've seen
- yet, vast portions are left to interpretations or even not specified
at all:
- the local filesystem comes to mind,
- also every browser has its own
24 matches
Mail list logo
