Hi Thomas and everyone,
So I realize that I'm not quite understanding your previous mail. It
sounds like you have some alternative proposal in mind which I'm not
following.
So let me start by stating my concerns:
My concern with the current spec is that once a server in the pre-flight
Anne van Kesteren wrote:
On Thu, 12 Jun 2008 23:01:10 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
│ This is the Document pointer.
If 'pointer' or 'Document pointer' is a term (which the styling
seems to indicate) then please add it to section 2.2.
The specification defines various terms
?
Look forward to hosting the members here in Redmond.
Looking forward to seeing you there!
Best Regards,
Jonas Sicking
Thomas Roessler wrote:
I think we've both been arguing this all over the place, and the
thread might be getting a bit incoherent.
So let's try to start over...
The question here is whether it makes sense to add fine-grained
controls to the authorization mechanisms to control -- in addition
to
It would be great if microsoft could do this.
Sunava Dutta wrote:
I LOVE the idea!
-Original Message-
From: Doug Schepers [mailto:[EMAIL PROTECTED]
Sent: Monday, June 16, 2008 12:39 PM
To: Chris Wilson
Cc: Ian Hickson; Sunava Dutta; Arthur Barstow; Marc Silbey; public-
webapps; Eric
trying to understand your concern.
Looking forward to continued discussion on these topics. There is
definitely some interesting stuff in here so I'm glad we got this feedback!
Best Regards,
Jonas Sicking
Julian Reschke wrote:
timeless wrote:
On Thu, Jun 19, 2008 at 1:09 PM, Julian Reschke
[EMAIL PROTECTED] wrote:
Can you provide an example where providing *XML* parse error information
within *XHR* would be problematic?
i really shouldn't have to. imagine a document that is not CSS and is
Maciej Stachowiak wrote:
On Jun 14, 2008, at 4:23 AM, Jonas Sicking wrote:
I must say though, this is starting to sound complex and I am not
totally convinced of the need to make servers opt in to getting
cookies. Is it really a likely mistake that someone would take
affirmative steps
Zhenbin Xu wrote:
[Zhenbin Xu] Regardless what different browser does today, rich
parsing
error is an important feature for developers. I have found it can
pinpoint
the exact problem that otherwise would have been difficult to
identify when
I sent incorrectly constructed XML file.
And
Ian Hickson wrote:
On Thu, 19 Jun 2008, Jonas Sicking wrote:
And it's useful for pages that contain private information only when
cookies are sent, but when no cookies are sent they only provide public
information. I've given two examples of this in other threads:
1. A news site serving
Zhenbin Xu wrote:
Sorry I accidently deleted part of reply. Inline...
-Original Message-
From: Jonas Sicking [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 19, 2008 2:17 PM
To: Zhenbin Xu
Cc: Anne van Kesteren; Sunava Dutta; IE8 Core AJAX SWAT Team; public-
[EMAIL PROTECTED]
Subject
Maciej Stachowiak wrote:
On Jun 19, 2008, at 1:48 PM, Jonas Sicking wrote:
Maciej Stachowiak wrote:
After reviewing your comments, I am much more inclined to favor
Microsoft's proposal on this: rename the relevant headers. I think
you argued that this doesn't scale, but I think only two
Ian Hickson wrote:
On Thu, 19 Jun 2008, Jonas Sicking wrote:
This only helps with servers that have same-domain pages that accept
cookies, but have no cross-domain pages that accept cookies, ever
(since if any of the cross-domain pages accept cookies, then our
initial assumption
Ian Hickson wrote:
On Thu, 19 Jun 2008, Jonas Sicking wrote:
The site is as always responsible for asking the user before allowing
third-party access to private data, and yes, if they fail to do so
properly they will be vulnerable.
So I guess I don't really understand what your proposal
Ian Hickson wrote:
On Thu, 19 Jun 2008, Jonas Sicking wrote:
So I guess I don't really understand what your proposal solves, then.
It seems like a lot of complexity for only a very minimal gain in only
one very specific scenario (the site doesn't ever return cookie-based
data cross-site
Ian Hickson wrote:
On Thu, 19 Jun 2008, Jonas Sicking wrote:
That is, your solution only works so long as the site doesn't ever opt in to
cookies. Which seems uncommon.
This is not true. You can opt in to cookies on just a subset of the URIs
where you opt in to Access-Control with my proposal
Can anyone really ever mention things that are member confidential on
IRC? We have no control over who else is in the room and possibly logging.
/ Jonas
Charles McCathieNevile wrote:
Hi Anne,
this raises a couple of issues - the obvious one being how we deal with
meetings which include
Ian Hickson wrote:
On Fri, 20 Jun 2008, Jonas Sicking wrote:
Under the current spec the operator must check each individual PHP
script in the part of the site that is shared to make sure that none of
them use $_SESSION, $_COOKIE, $HTTP_SESSION_VARS, $_ENV['HTTP_COOKIE'],
HttpRequest
Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
It makes no sense to me to for HTTP say that the total number of bytes
should include HTTP headers. It would be similar to including the TCP
headers in the IP packets IMHO.
There is a big difference here, an application might not have
Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
First off, as before, when I talk about cookies in this mail I really
mean cookies + digest auth headers + any other headers that carry the
users credentials to a site.
I don't quite see why you would mix these. Is there anywhere where I can
Charles McCathieNevile wrote:
Followup to webapps group please (reply-to set for this mail)
On Mon, 02 Jun 2008 23:56:22 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Charles McCathieNevile wrote:
On Sat, 31 May 2008 01:05:44 +0200, Jonas Sicking [EMAIL PROTECTED]
I wanted to implement
Zhenbin Xu wrote:
It should be revised to:
responseText:
If the state is not DONE, raise an INVALID_STATE_ERR exception and terminate
these steps.
This doesn't seem very consistent with the other response properties
though. Seems like .getResponseHeader and .getAllResponseHeaders work
Charles McCathieNevile wrote:
On Sun, 22 Jun 2008 10:32:50 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
It makes no sense to me to for HTTP say that the total number of
bytes should include HTTP headers. It would be similar to including
I don't think we have seen any alternative proposals for putting the
policy *enforcement* on the server. It also seems very hard to me to
rely on the server enforcing the policy, while still protecting legacy
servers, since they currently do not perform any such enforcement.
What I have
Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
I'm not quite following what you are asking here. My proposal is about
giving a site the ability to enable two modes of Access-Control:
1. Allow a third-party site to read the data on this resource, and/or
perform unsafe methods in HTTP
Sounds good to me.
/ Jonas
Doug Schepers wrote:
Hi, Jonas, Daniel-
Jonas Sicking wrote (on 6/23/08 2:03 PM):
What about the issue I raised here:
http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0214.html
Which no one replied to.
If you implement the HTML DOM you should
Maciej Stachowiak wrote:
Hi folks,
the agenda and logistics page for the meeting will be shortly
available to working group members (Sunava, can you please ask your AC
rep to ensure that you guys have joined by the time we have the
meeting?).
I would like to request an additional agenda
Arun Ranganathan wrote:
chaals et al.,
Yep. I am waiting for people to comment on whether they are happy to
roll up about 11 on Tuesday
I am happy enough with an 11a.m. start time; I suspect, however, that
our discussions will run over a bit, and thus, I think we ought to be
prepared
Maciej Stachowiak wrote:
On Jun 25, 2008, at 1:09 PM, Arun Ranganathan wrote:
Doug Schepers, Charles McCathieNevile (Chairs), Members of the WG,
On behalf of Mozilla, I'd like to introduce the possibility of two new
work items for this group to consider. Neither of these is presented
as
Doug Schepers wrote:
Hi, WebApps WG-
The WebApps F2F meeting page has been updated to reflect the current
agenda:
http://www.w3.org/2008/webapps/Group/f2f0807.html (member-only)
I do notice that some of the times are in what you americans call
'military time', and some times are in
Maciej Stachowiak wrote:
On Jun 28, 2008, at 2:33 PM, Jonas Sicking wrote:
Maciej Stachowiak wrote:
On Jun 27, 2008, at 2:18 PM, Jonas Sicking wrote:
What is the threat model this defends against? Since any server using
Access-Control that does not check HOST is vulnerable
NodeList (all except for Mozilla-based browsers, at least). I suspect that
building upon this existing work would lead to especially-fast adoption.
--John
- Original Message -
From: Doug Schepers [EMAIL PROTECTED]
To: Jonas Sicking [EMAIL PROTECTED]
Cc: Webapps public-webapps@w3.org, Web APIs
Maciej Stachowiak wrote:
On Jul 9, 2008, at 3:17 PM, Anne van Kesteren wrote:
On Wed, 09 Jul 2008 23:54:17 +0200, Sunava Dutta
[EMAIL PROTECTED] wrote:
I prefer
Access-control: *
Access-control: URL
I suppose it would be slightly shorter, but it's also less clear.
I would be in favor
Anne van Kesteren wrote:
On Wed, 09 Jul 2008 22:22:52 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
The name Access-Control-Origin is IMHO confusing.
It's more or less identical to how it works for Web sockets. (Called
Websocket-Origin there.)
If only we had the editor of that spec
Hi All,
During the F2F we talked about doing preflight-less POSTs in order to be
compatible with microsofts security model and allow them follow the AC
spec for their feature set.
Unfortunately when I brought this up at mozilla there was concern about
doing cross-site POSTing with content
Anne van Kesteren wrote:
On Thu, 10 Jul 2008 01:13:52 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
This is exactly how postMessage() works and it seems nice to align
with that.
I am very strongly against this syntax as it gives a false sense of
security
Anne van Kesteren wrote:
* Access-Control is now Access-Control-Origin which takes * or a URL.
In other words, whether or not a site grants access is simplified *a
lot*. Implementors who told me this was the most complex part to
implement can rejoice. This also makes this specification
Anne van Kesteren wrote:
On Thu, 10 Jul 2008 13:21:33 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Yes, I had gotten the impression that Flash would allow POSTs even if
there was no /crossdomain.xml file. I.e. that it would allow the
actual POST even if the preflight failed, it just
Kartikaya Gupta wrote:
On Thu, 17 Jul 2008 11:48:52 -0400, Boris Zbarsky [EMAIL PROTECTED] wrote:
There are countless other
implementations of MutationEvents out in the world
(http://google.com/codesearch?hl=enlr=q=DOMNodeRemoved+-mozilla+-webcoresbtn=Search).
They exist in more languages and
Kartikaya Gupta wrote:
On Wed, 16 Jul 2008 16:18:39 -0500, Jonas Sicking [EMAIL PROTECTED] wrote:
Laurens Holst wrote:
I see, so the motivation for the change request to DOMNodeRemoved is
that the second change request (throwing events at the end, after all
operations) is be impossible to do
Doug Schepers wrote:
Jonas proposes two substantive changes to this:
* DOMNodeRemoved and DOMNodeRemovedFromDocument would be fired after the
mutation rather than before
* DOM operations that perform multiple sub-operations (such as moving an
element) would be dispatched (in order of
detailed.
A few comments inline...
Jonas Sicking wrote (on 7/17/08 8:51 PM):
* Add a |readonly attribute long relatedIndex;| property to
the MutationEvent interface.
* Add a DOMChildRemoved event which is fired on a node when one
of its children is removed. The relatedNode property contains
Kartikaya Gupta wrote:
On Thu, 17 Jul 2008 17:51:42 -0700, Jonas Sicking [EMAIL PROTECTED] wrote:
* Add a DOMDescendantRemovedFromDocument event which is fired on a node
when the node is in a document, but any of nodes the descendants is
removed from the document. The event is fired
Maciej Stachowiak wrote:
On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote:
I’m in time pressure to lock down the header names for Beta 2 to
integrate XDR with AC. It seems no body has objected to Jonas’s
proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html
Jonas Sicking wrote:
Maciej Stachowiak wrote:
On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote:
I’m in time pressure to lock down the header names for Beta 2 to
integrate XDR with AC. It seems no body has objected to Jonas’s
proposal.
http://lists.w3.org/Archives/Public/public-webapps
Julian Reschke wrote:
Ian Hickson wrote:
On Mon, 21 Jul 2008, Julian Reschke wrote:
Ian Hickson wrote:
...
...which basically just says it's a valid URL if it's a valid URI or
IRI
(with some caveats in the case of IRIs to prevent legacy encoding
behaviour
from handling valid URLs in a
Stewart Brodie wrote:
Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Jul 16, 2008, at 5:00 PM, Stewart Brodie wrote:
Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Jul 16, 2008, at 2:03 PM, Stewart Brodie wrote:
I agree with all that, but it's not the whole story, because making
this
Cameron McCormack wrote:
XBL2 currently says:
The action taken (retarget vs. stop) is specific to the event type. In
general, UI events must be retargeted and mutation events must be
stopped. Exceptions to the rule are noted below. The goal of this
retargeting or stopping is to stop
Arthur Barstow wrote:
Hi Sam,
This seems like a reasonable extension to me.
A colleague asks Are there any new security concerns by putting this
inside XHR, or is the assumption that we are not exposing anything new?
What are your thoughts on that question? I presume not exposing
Sam Weinig wrote:
On Jul 28, 2008, at 10:45 AM, Jonas Sicking wrote:
Arthur Barstow wrote:
Hi Sam,
This seems like a reasonable extension to me.
A colleague asks Are there any new security concerns by putting this
inside XHR, or is the assumption that we are not exposing anything new
[mailto:[EMAIL PROTECTED]
Sent: Saturday, July 19, 2008 9:32 PM
To: Jonas Sicking
Cc: Sunava Dutta; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon
Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team
Subject: Re: XDomainRequest Integration with AC
On Jul 18, 2008, at 11:15 PM, Jonas Sicking
And note that this syntax should be supported even in the public data
scenario.
/ Jonas
Jonas Sicking wrote:
Please note that
Access-Control-Allow-Origin: url
is also allowed syntax. Where the url must contain only scheme, domain
and host.
So the following syntax is allowed:
Access
Adam Roben wrote:
On Jul 30, 2008, at 12:19 PM, Jonas Sicking wrote:
Please note that
Access-Control-Allow-Origin: url
is also allowed syntax. Where the url must contain only scheme, domain
and host.
Do you mean scheme, host, and port?
Yes :)
/ Jonas
Sunava Dutta wrote:
In offline conversations with Jonas on the topic of supporting the url
syntax I think Jonas mentioned a good point regarding supporting URL
for the private scenario. Namely, in caching scenarios allowing the
URL to be sent in the response header if mistakes happen (for
Anne van Kesteren wrote:
On Wed, 30 Jul 2008 18:19:20 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Please note that
Access-Control-Allow-Origin: url
is also allowed syntax. Where the url must contain only scheme, [host,
and port].
So the following syntax is allowed:
Access-Control-Allow
Ian Hickson wrote:
On Thu, 7 Aug 2008, Jonas Sicking wrote:
Ian Hickson wrote:
On Thu, 7 Aug 2008, Olli Pettay wrote:
Could we actually just say that if document implements DocumentView
interface and .defaultView isn't null and implements EventTarget,
the event propagates to .defaultView
Julian Reschke wrote:
Anne van Kesteren wrote:
On Fri, 08 Aug 2008 08:28:48 +0200, Jonas Sicking [EMAIL PROTECTED]
wrote:
Anne van Kesteren wrote:
My plan is to simply require Access-Control-Allow-Origin to hold
the ASCII serialization of an origin (see HTML5) and have a literal
Anne van Kesteren wrote:
On Wed, 30 Jul 2008 18:19:20 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Please note that
Access-Control-Allow-Origin: url
is also allowed syntax. Where the url must contain only scheme, [host,
and port].
So the following syntax is allowed:
Access-Control-Allow
Garrett Smith wrote:
The File object is useful for uploading files via XHR. It provides
functionality for data to be retrieved from a file submitted to a
formusing the input type file.
It is currently a Working Draft:
http://www.w3.org/TR/file-upload/
Jonas Sicking wrote:
Anne van Kesteren wrote:
On Fri, 08 Aug 2008 11:38:55 +0200, Jonas Sicking [EMAIL PROTECTED]
wrote:
String comparison is not going to be ok either way. The following two
origins are equivalent:
http://www.foo.com
http://www.foo.com:80
My proposal was to treat those
João Eiras wrote:
Hi !
I vote for having a new light weight object to completely replace the
current NSResolver, and then apply it to other DOM specs namely the
XPath DOM.
I had some of the problems we're discussing with the XPath DOM API, and
obviously the same apply here.
I exposed my
João Eiras wrote:
On , Jonas Sicking [EMAIL PROTECTED] wrote:
João Eiras wrote:
Hi !
I vote for having a new light weight object to completely replace
the current NSResolver, and then apply it to other DOM specs namely
the XPath DOM.
I had some of the problems we're discussing
João Eiras wrote:
Unfortunately I don't think we can change how XPath parses things
since there is already code out there that might rely on the current
behavior. Might be worth looking into though.
I don't want to worry about xpath, although that misfeautre bite me hard :)
Chaging the
Boris Zbarsky wrote:
Lachlan Hunt wrote:
The developers implementing this in Opera has given me feedback saying
that this shouldn't throw an exception because JS allows additional
arguments to be passed to any method, including other DOM APIs, like
getElementById(), etc. Is there a good
Garrett Smith wrote:
There are probably others but I can't think of them. I think the
majority of the time that strings will want to go to ToString,
booleans will want to go to ToBoolean.
That can be the default, perhaps. But I suspect usually null should become
, not null.
Why?
Note
Garrett Smith wrote:
On Mon, Aug 25, 2008 at 6:07 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
There are probably others but I can't think of them. I think the
majority of the time that strings will want to go to ToString,
booleans will want to go to ToBoolean.
That can
Garrett Smith wrote:
In some UAs that alerts null, in some it throws an exception because
createElement() is not valid. Just try it.
Using ToString, the following result would be obtained:
// ERROR
document.createElement();
// create a null element.
document.createElement(null);
//
One last time, the facts:
1) There are DOM methods that accept DOMString arguments or return
DOMString values.
Fact.
Sounds like you agree here.
2) In general, such methods need to be able to tell apart null and all
string values (including and null).
They need to determine
Garrett Smith wrote:
I don't agree that that is a good way to handle null, but it is clear
that these two:
document.body.textContent=null;
document.body.textContent='';
Are specified as being different from each other. They are different
because is the empty string and null is null. Agreed?
Anne van Kesteren wrote:
For when I next edit this draft (hopefully soon):
* Origin header shouldn't point to the origin definition.
* Exception codes need to be changed. (See XMLHTttpRequest Level 1.)
* Upload notifications should work non same origin as well.
* Download notifications
Anne van Kesteren wrote:
On Fri, 08 Aug 2008 20:44:04 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
The big worry I have though is if there is any possibility to puny
encode the same origin in multiple ways (other than with or without
default port). This could lead to different UAs encoding
Garrett Smith wrote:
On Fri, Sep 5, 2008 at 12:28 PM, Arun Ranganathan [EMAIL PROTECTED] wrote:
All,
Hi Arun,
On behalf of Mozilla, I'd like to take over as editor of the FileUpload
spec., which was actually once assigned to me quite some time ago :)
Of course, I think that
Garrett Smith wrote:
On Sun, Sep 7, 2008 at 8:47 AM, Erik Dahlström [EMAIL PROTECTED] wrote:
Hello webapps wg,
On behalf of the SVG WG I'd like to propose adding to the ProgressEvents
spec[1] an event equivalent to the 'loadend' (previously known as
'SVGPostLoad') event currently defined in
Anne van Kesteren wrote:
On Fri, 05 Sep 2008 02:36:58 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
1. A timeout property like the one on microsofts XDR. I haven't looked
into the specifics of XDRs property, but I would think that an
'abort' event should fire as well as readystate
Geoffrey Sneddon wrote:
On 9 Sep 2008, at 14:58, Dominique Hazael-Massieux wrote:
Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit :
HTTP has Content-Encoding and Transfer-Encoding, no? No special effort
on the part of XMLHttpRequest is needed to make use of those, as long
Kris Zyp wrote:
Well, at least when an outgoing XmlHttpRequest goes with a body, the
spec could require that upon setting the Content-Encoding header to
gzip or deflate, that the body be adequately transformed. Or is
there another e.g. to POST a gzip request with Content-Encoding?
Why can it
Kris Zyp wrote:
I suspect compression from the UA to the server will need support on
the XHR object in order to work. I don't think the right way to do
it is through setRequestHeader though, that seems like a hack at best.
I would have thought this would be negotiated by the server sending a
getting called? onreadystatechange is not fired any more
unless someone explicitly calls .abort() and then .open()?
/ Jonas
-Original Message-
From: [EMAIL PROTECTED] [mailto:public-webapps-
[EMAIL PROTECTED] On Behalf Of Jonas Sicking
Sent: Tuesday, September 09, 2008 2:56 PM
To: Anne van
Jonas Sicking wrote:
Sunava Dutta wrote:
XDR timeout doesn’t work with sync requests as there is no sync
support in the object.
I'd be thrilled if IE9's timeout property be adopted for XHR. (OK,
thrilled would be an understatement!)
http://msdn.microsoft.com/en-us/library/cc304105(VS.85
Stewart Brodie wrote:
Jonas Sicking [EMAIL PROTECTED] wrote:
Stewart Brodie wrote:
I disagree with any proposal that allows the application layer to
forcibly interfere with the transports layer's internal workings. Use
of encodings, persistent connections, on-the-fly compression
mike amundsen wrote:
I think a reasonable approach would be to offer an optional flag to
*attempt* compression on the upload.
When set to false (the default), no OPTION call would be made and
the content would be sent w/o any compression.
When set to true the component can make an OPTIONS call,
mike amundsen wrote:
If i understand you, you're saying the coding of the page (HTML/JS)
should 'know' that the target server does/does-not support compression
for uploads and handle it accordingly. I assume you mean, for
example, as a coder, I know serverX only allows posting an XML
document,
mike amundsen wrote:
Jonas:
snip
Your proposal with the flag seems like it's reverting to the having to
know case, since you'd want to set the flag if and only if the server
supports compression to avoid extra overheads, while still taking advantage
of compression when the server supports it.
of the component, etc.)
Mike A
On Thu, Sep 11, 2008 at 11:01 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
mike amundsen wrote:
Jonas:
snip
Your proposal with the flag seems like it's reverting to the having to
know case, since you'd want to set the flag if and only if the server
supports
"-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
new-zealand-swingers-
new-zealand-swingers-
Thread
Date
On Wed, Sep 17, 2008 at 3:03 AM, Sunava Dutta
[EMAIL PROTECTED] wrote:
Jonas said
I guess IE doesn't have an abort event on the XHR object (is this
correct?) so the relation between ontimeout and onabort is undefined as
far as the IE implementation goes.
Correct. We do have abort and
On Thu, Sep 25, 2008 at 12:35 PM, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Thu, 25 Sep 2008 21:26:05 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
However I think that if we are using URI syntax for these headers we
should treat them as URIs and not as opaque strings. Everywhere else
Anne van Kesteren wrote:
On Mon, 29 Sep 2008 18:03:43 -0400, Jonas Sicking [EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
Then I'll specify the former as special casing those methods here is
something I rather not do. I'd much rather have addEventListener,
addEventListenerNS, onprogress
Anne van Kesteren wrote:
On Mon, 29 Sep 2008 23:53:32 -0400, Jonas Sicking [EMAIL PROTECTED] wrote:
I agree we shouldn't prevent synthesized events. But why not say that
no ProgressEvents are dispatch at all?
That would prevent synthesized ProgressEvent events.
I mean
Arve Bersvendsen wrote:
On Tue, 30 Sep 2008 01:35:42 +0200, Marcos Caceres
[EMAIL PROTECTED] wrote:
Hi All,
I think we should dump the Widgets preferences API in favor of HTML5
DOM's storage API. Basically, preferences API basically replicates
what DOM Storage already defines. Also, DOM
Anne van Kesteren wrote:
On Fri, 03 Oct 2008 14:10:43 +0200, Anne van Kesteren [EMAIL PROTECTED]
wrote:
Since Jonas didn't e-mail about this I thought I would. Say
http://x.example/x does a request to http://y.example/y.
http://y.example/y redirects to http://x.example/y. If this request
Arthur Barstow wrote:
The following issues were created during the July 1-2 f2f meeting
(minutes at [1], [2], respectively).
Would someone that attended that meeting please elaborate these issues?
In particular, has the Issue been addressed and thus can be proposed to
be Closed?
Jonas Sicking wrote:
* ISSUE-30 Should spec have wording to recognise that User Agents may
implement further security beyond the spec?
http://www.w3.org/2008/webapps/track/issues/30
I guess this is the part that needs to be addressed by adding wording to
the spec to say that the cache can
Why did you ignore Apple's proposal to start with a minimal common
interface (which most people seemed to like) and instead wrote a
draft that
is the union of all things in Robin's original spec, all things that
Mozilla
happened to implement, and a bunch of the things that Google propose?
In bug 380418 [1] we have decided to completely block access to the
Set-Cookie header through XHR. This seems like the safest way to prevent
httpOnly cookies from leaking in to javascript.
In addition it seems good to block access to the raw network protocol
used for security and can
Charles McCathieNevile wrote:
Hi folks,
at
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.24
you will find a new draft of the progress events spec, for your
delectation...
So the spec says that for HEAD requests the size should include the size
of headers.
Garrett Smith wrote:
On Tue, Oct 21, 2008 at 5:32 PM, Garrett Smith [EMAIL PROTECTED] wrote:
On Tue, Oct 21, 2008 at 3:27 AM, Charles McCathieNevile
[EMAIL PROTECTED] wrote:
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.24
Hopefully this draft is ready for last
Garrett Smith wrote:
On Fri, Oct 24, 2008 at 5:51 AM, Jonas Sicking [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
I agree. Not sure if that is what you want to do before or after getting the
load/error/abort event though?
I should mention that I'm not particularly married to having things
Hear hear!
Charles McCathieNevile wrote:
Hi,
Lachy thinks the latest editor's draft[1] is ready for Last Call, after
responding to all the comments from last time (and removing the
NSResolver). The disposition of comments[2] explains what happened to
those comments.
So this is a call
Cameron McCormack wrote:
Hello WGs.
I’ve just committed changes to Web IDL on how it treats index and name
getters and setters. Browers don’t agree on some specifics of how the
index and name properties on HTMLCollections are handled, so I’ve tried
to make some sensible decisions in these
1 - 100 of 1790 matches
Mail list logo
