Re: XHR LC comments

[Julian Reschke]

Bjoern Hoehrmann wrote:

* Julian Reschke wrote:
- If the URL parameter can be a IRI, then somewhere later on we need to 
state that it needs to be transformed to a URI before it's put on the wire.


Actually that is for the HTTP specification to define, which right now
does so implicitly by allowing only URIs. Restating requirements usually
leads to specifications stating conflicting requirements, it's best not
done at all, except in informative notes clearly limited to the known
cases (e.g., "Note: Because HTTP/1.0 and HTTP/1.1 allow only URIs as
request URIs, user agents will transform the IRI to an URI when creating
the request message.", though I would not add this).


And HTTPbis is not going to change that, as referencing RFC3987 would be 
a downref.


XHR is defining an HTTP API. If that API allows IRIs where HTTP wants 
URIs, then I think it should be stated somewhere that a transformation 
needs to take place.


BR, Julian

Re: IE Team's Proposal for Cross Site Requests

[Bjoern Hoehrmann]

* Chris Wilson wrote:
>In both XHR2+AC and Flash's policy file approach, the "allow
>credentials" and the actual access to data occur in separate network
>transactions, and likely (but not guaranteed, of course) separate
>network connections.  This enables the vector of DNS attacks - the idea
>being that between those two connections, an attacker could insert
>themselves in to the stream.  (Actually, more likely it would be the
>other way around - an attacker would insert themselves into the stream,
>give back "it's okay to do x-domain", then release and let the real site
>give back data.

It is insufficient to describe what an attacker could do, you have to
show that an attacker can compromise a system only because of the new
feature. The attack you describe transforms cross site requests into
same origin requests, instead of injecting a spoofed OPTIONS response
the attacker could just as well inject a spoofed GET response and have
a script included that then has same-origin access to the site. What
you describe is essentially as powerful as a XSS vulnerability. There
may well be attack vectors that have not yet been considered, but this
is not one of them.

>XDR, by contrast, performs the "access check" in effect on the same
>connection, since it's not a multi-part negotiation.

If true, this is actually only so due to some undocumented implemen-
tation detail. At the moment the XDR implementation in the IE8 Beta
agressively bypasses caches, otherwise it would be vulnerable to the
"attack" you describe above because the attacker could inject a 304
response that updates the XDR header in a cached response and the
browser would then grant access to it despite the victim forbidding
that. As I understand it, "XHR2+AC" implementers want to cache the
responses, so I would expect them to by actually "vulnerable", but
see above.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[XHR] Dependencies in XHR

[Doug Schepers]

Hi, WebAPI WG-

It seems that there are multiple dependencies upon HTML 5.0 in the XHR 
specification.  As Team Contact, I would like to caution against this 
approach, as the HTML 5.0 specification is a long time from being 
stable, and this hinders implementation (particularly for vendors who 
sell their browsers, and must therefore market them).


If possible, I would like to identify all dependencies and see if we can 
remove them, or move them to a smaller, more manageable deliverable. 
Anne (the editor) has helpfully marked these in the spec, which I 
applaud as excellent speccing best practice.


"The terms origin and event handler DOM attribute are defined by the 
HTML 5 specification."


I believe that "origin" can be defined in the Window Object 
specification, one of this WG's explicit deliverables.


We have discussed adding consideration for "event handler DOM attribute" 
in the DOM3 Events spec, such that a host language can define what that 
means in its context



"Objects implementing the Window interface must provide an 
XMLHttpRequest()  constructor."


Again, see Window Object spec.

"If there is a Content-Type header which contains a text/html MIME type 
follow the rules set forth in the HTML 5 specification to determine the 
character encoding. Let charset be the determined character encoding."


This is not, strictly speaking, a dependency.  It is a matter of each 
host language defining its own value for charset.  Am I missing 
something here?



I know that everything in the spec is normative unless marked otherwise, 
but I just wanted to make sure that none of the references are informative?


Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Re: setRequestHeader / Accept

[Bjoern Hoehrmann]

* Maciej Stachowiak wrote:
>Using XHR with non-JavaScript programming languages seems pretty  
>unlikely.

http://www.google.com/codesearch?q=-lang%3Ajavascript+IXMLHTTPRequest
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Moving forward with XHR2 and AC

[Jonas Sicking]

Ian Hickson wrote:

On Sun, 25 May 2008, Jonas Sicking wrote:

Access Control for Cross-Site Requests

* Need to deal with Access-Control-Policy-Path normalization

Done.
I think we do need to deal with this. Just leaving it be will I think 
will cause exploitable servers out there.


I don't understand how this is different to anything else that servers can 
do to shoot themselves in the foot. I think that the danger for authors 
using misconfigured and IIS servers is far outweighed by the benefit to 
all authors in terms of the reduced load. Firing an OPTIONS request for 
every single request is a high cost.


It is different in its likelihood to happen. I think we can expect 
people to deploy all the features of this spec on IIS. We do have a 
requirement that the spec should be deployable on existing servers and I 
think we're currently failing that requirement.


What I suggest is that we prohibit the Access-Control-Policy-Path header 
from being used on URIs that include the string "..\", in escaped or 
unescaped form. One worry with this is if there are encodings which put 
the '.' or '\' characters to other codepoints than 2E and 5C 
respectively. I.e. would we need to forbid its use on URIs other than 
ones containing


(.|%2e)(.|%2e)(\|%5c)

/ Jonas

Re: Moving forward with XHR2 and AC

[Thomas Roessler]

On 2008-05-27 11:00:44 -0700, Jonas Sicking wrote:

> What I suggest is that we prohibit the Access-Control-Policy-Path
> header from being used on URIs that include the string "..\", in
> escaped or unescaped form. One worry with this is if there are
> encodings which put the '.' or '\' characters to other codepoints
> than 2E and 5C respectively. I.e.  would we need to forbid its
> use on URIs other than ones containing

That sounds like perpetuating a bad hack in a spec.  I'd rather see
us say -- in a note somewhere in the spec -- that servers will want
to be careful, and will want to, e.g., configure their respective
web application firewall to prevent this attack from occuring.

That's very different from having specific client conformance
requirements around this kind of server behavior.

-- 
Thomas Roessler, W3C  <[EMAIL PROTECTED]>

Proposal to work on Geolocation

[Ian Hickson]

Hi,

Google would like to volunteer some resources to work on a specification 
to provide a Geolocation API for the Web platform. Does anyone on the 
working group think we should not work on this? If not, please consider 
this a formal proposal from us to adopt a Geolocation API as a work item. 
Since we need broad working group agreement to add a work item, I propose 
that we set a deadline of June 4th for dissent, though as Chaals always 
says, positive assent would be preferred. :-) Chaals, could you do the 
honours of making this formal? Thanks!

Background:
   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0011.html
   http://code.google.com/p/google-gears/wiki/GeolocationAPI

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Proposal to work on Geolocation

[Doug Schepers]

Hi, Ian-

Thanks for this proposal.

I strongly believe that W3C should be working on this, and over the last 
few weeks, Mike Smith and I have been talking to key vendors and other 
parties to bring together the proper resources to do this, including 
some discussion at Google.  We have identified several interested parties.


In fact, I proposed on the WebApps WG charter to add this deliverable. 
However, the Advisory Committee's review of the charter indicated that 
the Membership wants this to happen in a dedicated Geolocation API WG.


The W3C intends to follow through on that, and to allocate Team 
resources to this valuable technology.  We will announce something 
formal soon.


Rest assured that Mike and I are intent on ensuring that there is no 
scope creep for this API, and that the Geolocation API WG will take a 
pragmatic, vendor-aware approach, and will act quickly.


Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Ian Hickson wrote (on 5/27/08 4:39 PM):


Hi,

Google would like to volunteer some resources to work on a specification 
to provide a Geolocation API for the Web platform. Does anyone on the 
working group think we should not work on this? If not, please consider 
this a formal proposal from us to adopt a Geolocation API as a work item. 
Since we need broad working group agreement to add a work item, I propose 
that we set a deadline of June 4th for dissent, though as Chaals always 
says, positive assent would be preferred. :-) Chaals, could you do the 
honours of making this formal? Thanks!


Background:
   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0011.html
   http://code.google.com/p/google-gears/wiki/GeolocationAPI

Cheers,


--

Re: Proposal to work on Geolocation

[Olli Pettay]

Ian Hickson wrote:


Hi,

Google would like to volunteer some resources to work on a specification
to provide a Geolocation API for the Web platform. 

Sounds great!


Does anyone on the
working group think we should not work on this? If not, please consider
this a formal proposal from us to adopt a Geolocation API as a work item.

Just wondering why WebAPI WG and why not UWA[1]?
How is this work, or is it, related to DCCI[2]?


br,

Olli

[1] http://www.w3.org/2007/uwa/Activity.html
[2] http://www.w3.org/TR/DPF/

Re: Proposal to work on Geolocation

[Doug Schepers]

Hi, Olli-

Olli Pettay wrote (on 5/27/08 4:57 PM):


Ian Hickson wrote:


Google would like to volunteer some resources to work on a specification
to provide a Geolocation API for the Web platform. 


Sounds great!


Yes, we're hoping that Google joins the dedicated Geolocation API WG 
(when it forms, assuming there's no unforeseen difficulties).




Just wondering why WebAPI WG and why not UWA[1]?


It would have been logical to work on it in WebApps, since it is a 
client-side API, but it is admittedly a complicated subject (especially 
in terms of the IPR), and it won't hurt to have it in a dedicated WG. 
Obviously, anyone in this WG is also welcome to join the Geolocation API WG.




How is this work, or is it, related to DCCI[2]?


Only related by subject.  There is some work on geolocation in DCCI, but 
it is more generic, and currently they are working only on the ontology. 
 The Geolocation API WG is intended to work specifically on a 
client-side API.


Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Re: Proposal to work on Geolocation

[Maciej Stachowiak]

On May 27, 2008, at 2:01 PM, Doug Schepers wrote:



Hi, Ian-

Thanks for this proposal.

I strongly believe that W3C should be working on this, and over the  
last few weeks, Mike Smith and I have been talking to key vendors  
and other parties to bring together the proper resources to do this,  
including some discussion at Google.  We have identified several  
interested parties.


In fact, I proposed on the WebApps WG charter to add this  
deliverable. However, the Advisory Committee's review of the charter  
indicated that the Membership wants this to happen in a dedicated  
Geolocation API WG.


The W3C intends to follow through on that, and to allocate Team  
resources to this valuable technology.  We will announce something  
formal soon.


Rest assured that Mike and I are intent on ensuring that there is no  
scope creep for this API, and that the Geolocation API WG will take  
a pragmatic, vendor-aware approach, and will act quickly.


I could not find record of any such objection in the Advisory  
Committee mailing list archives, or any record of an official W3C  
decision on this point. As Team contact, could you please explain who  
made this decision and on what basis?


Regards,
Maciej

Re: Moving forward with XHR2 and AC

[Jonas Sicking]

Thomas Roessler wrote:

On 2008-05-27 11:00:44 -0700, Jonas Sicking wrote:


What I suggest is that we prohibit the Access-Control-Policy-Path
header from being used on URIs that include the string "..\", in
escaped or unescaped form. One worry with this is if there are
encodings which put the '.' or '\' characters to other codepoints
than 2E and 5C respectively. I.e.  would we need to forbid its
use on URIs other than ones containing


That sounds like perpetuating a bad hack in a spec.  I'd rather see
us say -- in a note somewhere in the spec -- that servers will want
to be careful, and will want to, e.g., configure their respective
web application firewall to prevent this attack from occuring.

That's very different from having specific client conformance
requirements around this kind of server behavior.


I really dislike it too, but just putting a "be careful" note in the 
spec isn't going to help anyone.


If we don't put this in the spec I suspect that in reality this is 
something that implementations are going to want to do anyway. I guess 
I'm fine with having this as a non-normative note to ensure that 
implementations that want to be on the safe side can.


But at that point we might as well enforce it in the spec too so that 
sites can rely on it.


/ Jonas

Re: Proposal to work on Geolocation

[Doug Schepers]

Hi, Maciej-

Maciej Stachowiak wrote (on 5/27/08 5:38 PM):


I could not find record of any such objection in the Advisory Committee 
mailing list archives, or any record of an official W3C decision on this 
point. As Team contact, could you please explain who made this decision 
and on what basis?


There was a substantive AC Representatives review comment regarding this 
deliverable, but it was a Team-only comment, and thus there's not much I 
can say about it.  It's not my favorite way of operating, and I wish I 
could say more, but at the same time, I have to honor Member 
confidentiality.


You can see my original charter proposal here (an earlier draft that 
includes the Geolocation API):

  http://www.w3.org/2007/12/WebApps-Charter/WebApp-Charter-2007-proposed
  http://www.w3.org/2007/12/WebApps-Charter/webapps-deliverables.html


I want to reiterate that W3C is *not* dropping the Geolocation API... we 
merely propose to move it to a dedicated WG.  I am ambivalent about this 
myself: on the one hand, I think there is considerable momentum and 
interest in doing this in the WebApps WG; on the other, it's a subject 
that many Members may want to join, who are not necessarily interested 
in other WebApps deliverables.


There is something to be said for having a subject covered exclusively 
by a dedicated WG with a manageable mailing list load, too. :)


Again, we are actively encouraging all interested parties to join this 
new Geolocation WG, and we will expedite its creation as far as we can. 
 Don't panic. :)


Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Re: Proposal to work on Geolocation

[Ian Hickson]

On Tue, 27 May 2008, Doug Schepers wrote:
> 
> The W3C intends to follow through on that, and to allocate Team 
> resources to this valuable technology.  We will announce something 
> formal soon.
> 
> Rest assured that Mike and I are intent on ensuring that there is no 
> scope creep for this API, and that the Geolocation API WG will take a 
> pragmatic, vendor-aware approach, and will act quickly.

Sure, the proposal to work in the Web API working group is only intended 
to be a stop-gap measure while we wait for the wheels of the W3C to turn. 
It would be sad to delay this while we wait for charters to be written and 
so forth.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Proposal to work on Geolocation

[Ian Hickson]

On Tue, 27 May 2008, Doug Schepers wrote:
> 
> I want to reiterate that W3C is *not* dropping the Geolocation API... we 
> merely propose to move it to a dedicated WG. [...]
> 
> Again, we are actively encouraging all interested parties to join this 
> new Geolocation WG, and we will expedite its creation as far as we can.  

Do you know when the AC review for this new WG will start?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [XHR] Dependencies in XHR

[Anne van Kesteren]

On Tue, 27 May 2008 18:59:38 +0200, Doug Schepers <[EMAIL PROTECTED]> wrote:
It seems that there are multiple dependencies upon HTML 5.0 in the XHR  
specification.  As Team Contact, I would like to caution against this  
approach, as the HTML 5.0 specification is a long time from being  
stable, and this hinders implementation (particularly for vendors who  
sell their browsers, and must therefore market them).


Vendors have actually requested this. The problem is summarized here:

  http://lists.w3.org/Archives/Public/public-webapi/2008May/0249.html


If possible, I would like to identify all dependencies and see if we can  
remove them, or move them to a smaller, more manageable deliverable.  
Anne (the editor) has helpfully marked these in the spec, which I  
applaud as excellent speccing best practice.


"The terms origin and event handler DOM attribute are defined by the  
HTML 5 specification."


I believe that "origin" can be defined in the Window Object  
specification, one of this WG's explicit deliverables.


In theory it could, yes. Until someone has done that it seems better for  
implementations to reference HTML5 as that has a better definition at the  
moment.



We have discussed adding consideration for "event handler DOM attribute"  
in the DOM3 Events spec, such that a host language can define what that  
means in its context


Again, HTML5 currently has a better definition.


"Objects implementing the Window interface must provide an  
XMLHttpRequest()  constructor."


Again, see Window Object spec.


The Window Object specification is not being maintained.


"If there is a Content-Type header which contains a text/html MIME type  
follow the rules set forth in the HTML 5 specification to determine the  
character encoding. Let charset be the determined character encoding."


This is not, strictly speaking, a dependency.  It is a matter of each  
host language defining its own value for charset.  Am I missing  
something here?


It's about determining the character encoding out of a stream of bytes.


I know that everything in the spec is normative unless marked otherwise,  
but I just wanted to make sure that none of the references are  
informative?


There is one non-normative reference to HttpOnly cookies in the editor's  
draft, see:


  http://dev.w3.org/2006/webapi/XMLHttpRequest/#bibref


--
Anne van Kesteren

Re: Proposal to work on Geolocation

[Doug Schepers]

Hi, Ian-

Ian Hickson wrote (on 5/27/08 6:09 PM):

On Tue, 27 May 2008, Doug Schepers wrote:


The W3C intends to follow through on that, and to allocate Team 
resources to this valuable technology.  We will announce something 
formal soon.


Rest assured that Mike and I are intent on ensuring that there is no 
scope creep for this API, and that the Geolocation API WG will take a 
pragmatic, vendor-aware approach, and will act quickly.


Sure, the proposal to work in the Web API working group is only intended 
to be a stop-gap measure while we wait for the wheels of the W3C to turn. 
It would be sad to delay this while we wait for charters to be written and 
so forth.


That's a very reasonable concern.  Since we are hoping for the WebApps 
WG to be chartered as soon as we hear back from the AC reps (hopefully a 
couple of weeks or less), it may not be appropriate to do it here... let 
me do some digging regarding an appropriate forum at W3C, and get back 
to you in the next couple of days.


In trying to manage expectations, I may have overstated the case, for 
what it's worth... there hasn't been a formal decision by W3M on this 
matter, merely a proposal for moving forward effectively, in a manner 
that best serves all parties.  It's not a fait accompli, and I shouldn't 
have represented it that way.  But a new Geolocation API WG seems a 
sensible solution, on the face of it, and I hope that you'll all support 
the idea.


In the meantime, I've removed the proposed Geolocation API from the 
WebApps charter.


Regarding proposed deliverables in general, I've provided a mechanism 
for that which I hope will be more agile, while providing due 
oversight... rather than rechartering the WG, we can merely present a 
proposal to the AC (based on initial use cases, requirements, research, 
etc.), and formally add it to our list of deliverables upon approval.  I 
anticipate steady progress in this group, so as we free up resources, we 
should keep looking forward for useful things that we can work on.


Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Re: Proposal to work on Geolocation

[Charles McCathieNevile]

On Tue, 27 May 2008 23:38:37 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:



On May 27, 2008, at 2:01 PM, Doug Schepers wrote:

...
In fact, I proposed on the WebApps WG charter to add this deliverable.  
However, the Advisory Committee's review of the charter indicated that  
the Membership wants this to happen in a dedicated Geolocation API WG.


The W3C intends to follow through on that, and to allocate Team  
resources to this valuable technology.  We will announce something  
formal soon.

...
I could not find record of any such objection in the Advisory Committee  
mailing list archives, or any record of an official W3C decision on this  
point. As Team contact, could you please explain who made this decision  
and on what basis?


In which case I presume that someone used their ability to reply to the  
Team privately instead of being open about what they wanted. This disturbs  
me a little since it increases the resources and coordination required,  
IMHO, to do what is a pretty simple piece of work.


For the record, Opera would also like to see the geolocation work take  
place inside the webAPI group and is unhappy that it has been removed from  
the proposed charter for Web Apps.


Cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Re: Proposal to work on Geolocation

[Doug Schepers]

Hi, Ian-

Ian Hickson wrote (on 5/27/08 6:20 PM):

On Tue, 27 May 2008, Doug Schepers wrote:


I want to reiterate that W3C is *not* dropping the Geolocation API... we 
merely propose to move it to a dedicated WG. [...]


Again, we are actively encouraging all interested parties to join this 
new Geolocation WG, and we will expedite its creation as far as we can.  


Do you know when the AC review for this new WG will start?


Not at the moment, but we are looking into it aggressively.  I'll keep 
you posted as we make progress.


Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Re: [WebIDL] Passing null and undefined to DOMString things

[Jonas Sicking]

It sounds like a bad idea to me that the default behavior for DOMString 
should be that null is converted to "null". I can't think of a single 
case where that is what you want to do.


Granted, this is partially due to a javascript spec "bug", null really 
should have serialized to "" rather than "null".


Since DOM Level 1 DOMStrings have had null as a legal value, so when 
passing null to a string argument there is usually no need to do any 
conversion.


When passing null to a [NotNull] string argument I think we should do 
the same thing as when passing null to any other [NotNull] argument, 
which IMHO should mean throwing.


Though looking at the spec it no longer looks possible to say that a 
function excepting an object doesn't want null. Was that removed or was 
it never there? I thought that was how this whole thing started, so that 
we could for example mark up that Node.appendChild does not accept null 
as a valid argument.


/ Jonas

Cameron McCormack wrote:

I’ve made DOMString an intrinsic type in the IDL now (to avoid the
“polite fiction”, as Maciej put it ☺).  I’ve also replaced [NoNull]
with [Null] and [Undefined], which can be used to specify how null and
undefined are treated when passed as an operation argument or assigned
to an attribute.

  
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?rev=1.73&content-type=text/html;%20charset=utf-8#idl-DOMString
  
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?rev=1.73&content-type=text/html;%20charset=utf-8#Null
  
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?rev=1.73&content-type=text/html;%20charset=utf-8#Undefined


Cameron McCormack:

[treating null as ""]


Maciej Stachowiak:
It needs to for many standard DOM methods. Most core DOM methods that  
take namespaces treat a null namespaceURI or prefix parameter the same  
as the empty string, not the same as the string "null".


I still think that for namespace URIs, the null value is what represents
no namespace, while "" can just be used as an alias for this.  This is
what DOM 3 Core says:

  Applications should use the value null as the namespaceURI  parameter
  for methods if they wish to have no namespace. In programming
  languages where empty strings can be differentiated from null, empty
  strings, when given as a namespace URI, are converted to null. This is
  true even though the DOM does no lexical checking of URIs.
   — 
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Namespaces-Considerations


Maciej Stachowiak:
I think DOM properties (and sometimes methods and function arguments) 
vary on this. Some use the raw ECMAScript ToString algorithm. Others 
additionally map the null value to the empty string instead of "null". 
Still others map the undefined value to "undefined". Some do both. I am 
pretty sure that for compatibility reasons you can't just do the same 
for each, so we may as well just define and test the legacy behavior for 
each one. Whatever is most common can be the default, and others can be 
marked up in the IDL appropriately.


Ian Hickson:
For both DOMString attributes and DOMString arguments, we have the 
following ways to handle null and undefined:

…
I think what we need is for WebIDL to have annotations for these cases, 
which can be prefixed in front of any occurance of "DOMString" in any IDL 
block, and then we can work down the APIs and check each DOMString 
occurance and work out which the UAs are doing. Say:


   [Null=Null, Undefined=Null]
   [Null=Null, Undefined=Empty]
   [Null=Empty, Undefined=Empty]
   [Null=Null, Undefined=String]
   [Null=Empty, Undefined=String]
   [Null=String, Undefined=String]

...so that we can do, e.g.:

   Window open([Null=String, Undefined=String] in DOMString url,
   [Null=String, Undefined=Empty] in DOMString name,
   [Null=Empty, Undefined=Empty] in DOMString features);

...or whatever is appropriate.


I have replaced [NoNull] with [Null] and [Undefined].  The default
behaviour for both null and undefined is to stringify, since that seemed
to be most common in some (not completely extensive) tests that I did:

  http://mcc.id.au/2007/05/binding-tests/tests/test.pl?id=061
  http://mcc.id.au/2007/05/binding-tests/tests/test.pl?id=062

So now you can specify [Null=Null], [Null=Empty], [Undefined=Null],
[Undefined=Empty].  You cannot specify stringification though; that’s
just the behaviour if the extended attribute is omitted.

Although stringifying null to "null" is more common than passing it
through, I sort of feel like [Null=Null] should be the default, since I
still think of null being one of the values in the DOMString type.  But
at least as it is now, the two extended attributes are consistent (they
both take either Null or Empty).


Cameron McCormack:

Should the Bindings spec require that the constructor return an object
that implements that interface?


Anne van Kesteren:

That would ma

Re: Proposal to work on Geolocation

[Doug Schepers]

Hi, Chaals-

Charles McCathieNevile wrote (on 5/27/08 6:34 PM):


On Tue, 27 May 2008 23:38:37 +0200, Maciej Stachowiak <[EMAIL PROTECTED]> 
wrote:


I could not find record of any such objection in the Advisory 
Committee mailing list archives, or any record of an official W3C 
decision on this point. As Team contact, could you please explain who 
made this decision and on what basis?


In which case I presume that someone used their ability to reply to the 
Team privately instead of being open about what they wanted. This 
disturbs me a little since it increases the resources and coordination 
required, IMHO, to do what is a pretty simple piece of work.


I think you may be overstating how simple this is, for what it's worth. 
 Exposing coordinates sounds simple, sure... but the security and 
privacy implications are stickier, as is the legal landscape (both in 
terms of privacy laws and of IPR).



For the record, Opera would also like to see the geolocation work take 
place inside the webAPI group and is unhappy that it has been removed 
from the proposed charter for Web Apps.


Noted.  I will convey your sentiments to the Team.

Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Re: [XHR] Dependencies in XHR

[Doug Schepers]

Hi, Anne-

Anne van Kesteren wrote (on 5/27/08 6:24 PM):

On Tue, 27 May 2008 18:59:38 +0200, Doug Schepers <[EMAIL PROTECTED]> wrote:
It seems that there are multiple dependencies upon HTML 5.0 in the XHR 
specification.  As Team Contact, I would like to caution against this 
approach, as the HTML 5.0 specification is a long time from being 
stable, and this hinders implementation (particularly for vendors who 
sell their browsers, and must therefore market them).


Vendors have actually requested this. The problem is summarized here:

  http://lists.w3.org/Archives/Public/public-webapi/2008May/0249.html


Well... that's not quite a normative reference. :)

Could you please point to a specific request from a vendor requesting 
that, rather than to your own email stating the claim?



If possible, I would like to identify all dependencies and see if we 
can remove them, or move them to a smaller, more manageable 
deliverable. Anne (the editor) has helpfully marked these in the spec, 
which I applaud as excellent speccing best practice.


"The terms origin and event handler DOM attribute are defined by the 
HTML 5 specification."


I believe that "origin" can be defined in the Window Object 
specification, one of this WG's explicit deliverables.


In theory it could, yes. Until someone has done that it seems better for 
implementations to reference HTML5 as that has a better definition at 
the moment.


I'm not convinced that it's better, since this is an LC draft.  That 
means the WG thinks it's done, and thus that dependency will persist.



We have discussed adding consideration for "event handler DOM 
attribute" in the DOM3 Events spec, such that a host language can 
define what that means in its context


Again, HTML5 currently has a better definition.


Okay, I'll work on that.


"Objects implementing the Window interface must provide an 
XMLHttpRequest()  constructor."


Again, see Window Object spec.


The Window Object specification is not being maintained.


True.  Maybe we need to reprioritize, then.

Hey, Browser Implementors!  Anyone got an editor to spare?


"If there is a Content-Type header which contains a text/html MIME 
type follow the rules set forth in the HTML 5 specification to 
determine the character encoding. Let charset be the determined 
character encoding."


This is not, strictly speaking, a dependency.  It is a matter of each 
host language defining its own value for charset.  Am I missing 
something here?


It's about determining the character encoding out of a stream of bytes.


Sure.  Is there some reason this can't be made generic and left to the 
host language to define?



I know that everything in the spec is normative unless marked 
otherwise, but I just wanted to make sure that none of the references 
are informative?


There is one non-normative reference to HttpOnly cookies in the editor's 
draft, see:


  http://dev.w3.org/2006/webapi/XMLHttpRequest/#bibref


Okay, thanks.


--
Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Re: Proposal to work on Geolocation

[Robert Sayre]

The WebAPI WG seems like the best venue.

- Original message -
Hi, Chaals- Charles McCathieNevile wrote (on 5/27/08 6:3...



On 5/27/08, Doug Schepers <[EMAIL PROTECTED]> wrote:
>
> Hi, Chaals-
>
> Charles McCathieNevile wrote (on 5/27/08 6:34 PM):
>>
>> On Tue, 27 May 2008 23:38:37 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>
>> wrote:
>>
>>> I could not find record of any such objection in the Advisory
>>> Committee mailing list archives, or any record of an official W3C
>>> decision on this point. As Team contact, could you please explain who
>>> made this decision and on what basis?
>>
>> In which case I presume that someone used their ability to reply to the
>> Team privately instead of being open about what they wanted. This
>> disturbs me a little since it increases the resources and coordination
>> required, IMHO, to do what is a pretty simple piece of work.
>
> I think you may be overstating how simple this is, for what it's worth.
>   Exposing coordinates sounds simple, sure... but the security and
> privacy implications are stickier, as is the legal landscape (both in
> terms of privacy laws and of IPR).
>
>
>> For the record, Opera would also like to see the geolocation work take
>> place inside the webAPI group and is unhappy that it has been removed
>> from the proposed charter for Web Apps.
>
> Noted.  I will convey your sentiments to the Team.
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG, CDF, and WebAPI
>
>

-- 
Sent from Gmail for mobile | mobile.google.com


Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Re: Proposal to work on Geolocation

[Jonas Sicking]

On Tue, 27 May 2008 23:38:37 +0200, Maciej Stachowiak <[EMAIL PROTECTED]> 
wrote:


I could not find record of any such objection in the Advisory 
Committee mailing list archives, or any record of an official W3C 
decision on this point. As Team contact, could you please explain who 
made this decision and on what basis?


In which case I presume that someone used their ability to reply to 
the Team privately instead of being open about what they wanted. This 
disturbs me a little since it increases the resources and coordination 
required, IMHO, to do what is a pretty simple piece of work.


I think you may be overstating how simple this is, for what it's worth. 
 Exposing coordinates sounds simple, sure... but the security and 
privacy implications are stickier, as is the legal landscape (both in 
terms of privacy laws and of IPR).


I think this group is doing a lot of work which involves privacy issues, 
with more specs concerning them coming, so dealing with those would be 
no new task.


Dealing with IPR issues would be something we haven't done though. 
Though given todays patent law, it seems like something that we likely 
have to deal with sooner or later no matter what.


The big missing piece would be geolocation itself I would say :)

All in all I would be in favor of doing that spec in this WG.

/ Jonas

Re: [XHR] Dependencies in XHR

[Anne van Kesteren]

On Wed, 28 May 2008 00:58:45 +0200, Doug Schepers <[EMAIL PROTECTED]> wrote:

 Vendors have actually requested this. The problem is summarized here:
   http://lists.w3.org/Archives/Public/public-webapi/2008May/0249.html


Well... that's not quite a normative reference. :)


It was not a reference for that claim, it was a reference for the issue we  
have. It seems you're suggesting you rather leave it underdefined?



Could you please point to a specific request from a vendor requesting  
that, rather than to your own email stating the claim?


  http://lists.w3.org/Archives/Public/public-webapi/2008May/0245.html


I believe that "origin" can be defined in the Window Object  
specification, one of this WG's explicit deliverables.
 In theory it could, yes. Until someone has done that it seems better  
for implementations to reference HTML5 as that has a better definition  
at the moment.


I'm not convinced that it's better, since this is an LC draft.  That  
means the WG thinks it's done, and thus that dependency will persist.


It means the WG agrees that the concept referenced is important to the  
draft. If the concept moves to another draft the WG would surely agree  
that referencing the new draft where the concept is defined is acceptable.


More concrete, if Window moves out of HTML5 into its own separate  
specification updating the XMLHttpRequest CR to point to this new  
specification is a trivial matter. However, so far we have not seen any  
evidence of that happening so it seems better to reference HTML5 as it is  
still being updated in response to comments, etc.



We have discussed adding consideration for "event handler DOM  
attribute" in the DOM3 Events spec, such that a host language can  
define what that means in its context


 Again, HTML5 currently has a better definition.


Okay, I'll work on that.


Great, though note that we reference DOM Level 2 Events currently as that  
is more stable and does everything XMLHttpRequest requires. Referencing  
DOM Level 3 Events instead would actually increase the number of instable  
dependencies.



"If there is a Content-Type header which contains a text/html MIME  
type follow the rules set forth in the HTML 5 specification to  
determine the character encoding. Let charset be the determined  
character encoding."


This is not, strictly speaking, a dependency.  It is a matter of each  
host language defining its own value for charset.  Am I missing  
something here?

 It's about determining the character encoding out of a stream of bytes.


Sure.  Is there some reason this can't be made generic and left to the  
host language to define?


I'm not sure what you're talking about here.


Note that we also rely on HTML5 for document.innerHTML to define proper  
serialization of a Document object.



--
Anne van Kesteren

Re: Proposal to work on Geolocation

[Ian Hickson]

On Tue, 27 May 2008, Doug Schepers wrote:
> > >
> > > Again, we are actively encouraging all interested parties to join 
> > > this new Geolocation WG, and we will expedite its creation as far as 
> > > we can.
> > 
> > Do you know when the AC review for this new WG will start?
> 
> Not at the moment, but we are looking into it aggressively.  I'll keep 
> you posted as we make progress.

Cool, thanks.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [WebIDL] ToString( Null ) => "null" :: Ecma-262 r3

[Garrett Smith]

On Tue, May 27, 2008 at 3:38 PM, Jonas Sicking <[EMAIL PROTECTED]> wrote:
>

Hey Jonas,

> Granted, this is partially due to a javascript spec "bug", null really
> should have serialized to "" rather than "null".
>

The value null, when passed to ToString, converts to the string
literal "null". I don't agree that that's a bug. This is how the
language was designed and I think it was a right choice. Other
programming languages use this approach, too. I think it is intuitive
because:

var el = document.getElementById( arg );
console.log( el );

- will print "null" to the console, if arg is not found (resulting in
el being null). This is useful.

It is very simple, when desired, to do:-

if(s === null) s = "";

It would seem wrong for null to convert to the string "" when passed
to ToString.

I don't suppose you'd rather have ToString( Undefined ) to result in
"undefined"?

Garrett

Re: XHR header blacklist rationale

[Jonas Sicking]

I also made it clear that the user agent is not to set any headers 
other than those on that list and those permitted to be set if the 
author has not set them (as explained under the send() algorithm).


So, why are the headers below on the list?

* Accept-Charset
* Accept-Encoding


I do see a reason why a UA wouldn't want content to set these.

Which charsets and encoding a UA supports is currently very UA 
dependent. Currently this is ok since it's a feature not exposed to web 
content, but rather just an interface between the server and the UA.


If web content can set these headers it is highly likely that pages will 
inadvertently create UA dependent pages that work if the UA supports 
some encodings, but break in UAs that don't. It would effectively force 
all UAs to support some standard set of encodings in order to work with 
the web.



* Expect


Don't know much about this header so i'll let others speak here.


* Referer
* User-Agent


These should absolutely not be under control of web content.

The Referer header is used by some web servers for security checks so 
allowing this to be settable would work around that. Servers can't 
currently rely on the header being there due to some firewalls/proxies 
filtering it, however they can rely on it being true when it is there.


The User-Agent is used a lot for logging and measuring various aspects 
(OS, UA, etc) of the user base for a site. Allowing this to be "spoofed" 
by a web page would severely reduce its usefulness. You cite in a 
different mail that you want to be able to set this to work around 
servers that send different content based to different UAs based on this 
header. However if we let this header be set by web content then servers 
would not be able to rely on the User-Agent header and would likely 
start using even worse mechanisms.


/ Jonas

Re: XHR header blacklist rationale

[Julian Reschke]

Jonas Sicking wrote:

These should absolutely not be under control of web content.

The Referer header is used by some web servers for security checks so 
allowing this to be settable would work around that. Servers can't 
currently rely on the header being there due to some firewalls/proxies 
filtering it, however they can rely on it being true when it is there.


The User-Agent is used a lot for logging and measuring various aspects 
(OS, UA, etc) of the user base for a site. Allowing this to be "spoofed" 
by a web page would severely reduce its usefulness. You cite in a 
different mail that you want to be able to set this to work around 
servers that send different content based to different UAs based on this 
header. However if we let this header be set by web content then servers 
would not be able to rely on the User-Agent header and would likely 
start using even worse mechanisms.


Microsoft's ActiveX version of XMLHTTPRequest definitively lets clients 
set it. I know it, because it was needed to override the UA header, so 
that servers would do proper authentication instead of form-based login.


Not sure about what the native implementations do today, but I think we 
need to make sure that the XHR spec doesn't break use cases that work today.


BR, Julian

Re: Proposal to work on Geolocation

[Ian Hickson]

On Tue, 27 May 2008, Doug Schepers wrote:
> Ian Hickson wrote (on 5/27/08 6:09 PM):
> > On Tue, 27 May 2008, Doug Schepers wrote:
> > > 
> > > The W3C intends to follow through on that, and to allocate Team 
> > > resources to this valuable technology.  We will announce something 
> > > formal soon.
> > > 
> > > Rest assured that Mike and I are intent on ensuring that there is no 
> > > scope creep for this API, and that the Geolocation API WG will take 
> > > a pragmatic, vendor-aware approach, and will act quickly.
> > 
> > Sure, the proposal to work in the Web API working group is only 
> > intended to be a stop-gap measure while we wait for the wheels of the 
> > W3C to turn. It would be sad to delay this while we wait for charters 
> > to be written and so forth.
> 
> That's a very reasonable concern.  Since we are hoping for the WebApps 
> WG to be chartered as soon as we hear back from the AC reps (hopefully a 
> couple of weeks or less), it may not be appropriate to do it here...

To clarify, we do consider two weeks to be a "wait". To be honest we're 
worried that with vendors already working on products that do Geolocation 
stuff, we may have waited too long already. The sooner we can get people 
together to discuss this the better.

In fact, would it be possible to unofficially use this mailing list to 
discuss proposals while we wait for a formal decision from Chaals on 
whether Geolocation can (even temporarily) be a WebAPI work item?


> Regarding proposed deliverables in general, I've provided a mechanism 
> for that which I hope will be more agile, while providing due 
> oversight... rather than rechartering the WG, we can merely present a 
> proposal to the AC (based on initial use cases, requirements, research, 
> etc.), and formally add it to our list of deliverables upon approval.  
> I anticipate steady progress in this group, so as we free up resources, 
> we should keep looking forward for useful things that we can work on.

FWIW, the resources Google has to offer here aren't locked to working 
groups, they're locked to work items. So insofar as Google is concerned, 
it would make no difference if there was one group or ten, we'd have the 
same amount of resources. The list of deliverables that matters is the 
total of all the deliverables we're interested in, not the deliverables 
that a particular working group is tasked to work on.

Having said that, I personally do think it would be wiser to keep all DOM 
APIs intended for browsers in one working group. The confusion we had with 
two working groups (WebAPI and WAF) led to us merging them, it would be 
sad to then immediately forget the lesson we had learnt and split work up 
again.

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [XHR] Dependencies in XHR

[Doug Schepers]

Hi, Anne-

Anne van Kesteren wrote (on 5/27/08 7:17 PM):


On Wed, 28 May 2008 00:58:45 +0200, Doug Schepers <[EMAIL PROTECTED]> wrote:

 Vendors have actually requested this. The problem is summarized here:
   http://lists.w3.org/Archives/Public/public-webapi/2008May/0249.html


Well... that's not quite a normative reference. :)


It was not a reference for that claim, it was a reference for the issue 
we have. It seems you're suggesting you rather leave it underdefined?


No, I want it defined somewhere that there isn't a long wait on a 
dependency chain.  I assume you're not claiming that vendors have asked 
for the opposite... but I'd be entertained by a link to that reference. :)


Seriously, I'm not sure what your point was here... I explained that 
commercial browser vendors prefer stable, mature specs, without 
unresolved dependencies... could you clarify why that isn't a concern?




We have discussed adding consideration for "event handler DOM 
attribute" in the DOM3 Events spec, such that a host language can 
define what that means in its context


 Again, HTML5 currently has a better definition.


Okay, I'll work on that.


Great, though note that we reference DOM Level 2 Events currently as 
that is more stable and does everything XMLHttpRequest requires. 
Referencing DOM Level 3 Events instead would actually increase the 
number of instable dependencies.


Yes, let's reevaluate that in light of progress on DOM3 Events shortly.


Sure.  Is there some reason this can't be made generic and left to the 
host language to define?


I'm not sure what you're talking about here.


I'm asking for an explanation about the nature of the dependency, vis a 
vis the necessary level of details in XHR.



Note that we also rely on HTML5 for document.innerHTML to define proper 
serialization of a Document object.


Noted.  Any proposal on how that can be resolved?

Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Re: Proposal to work on Geolocation

[Doug Schepers]

Hi, Ian-

Ian Hickson wrote (on 5/27/08 7:38 PM):

On Tue, 27 May 2008, Doug Schepers wrote:


That's a very reasonable concern.  Since we are hoping for the WebApps 
WG to be chartered as soon as we hear back from the AC reps (hopefully a 
couple of weeks or less), it may not be appropriate to do it here...


To clarify, we do consider two weeks to be a "wait". 


Hey, it's only a week more than your original proposal. :)



To be honest we're
worried that with vendors already working on products that do Geolocation 
stuff, we may have waited too long already. The sooner we can get people 
together to discuss this the better.


Sure, agreed as a general sentiment.  But honestly, is there some time 
pressure such that an extra week or two will cause serious problems? 
Vendors have been working in this space for many, many years (especially 
in Japan) and there are already tons of patents and different 
approaches... is there some particular issue that has more urgency than 
is generally known, which you'd care to share?  Or more likely, is it a 
case of momentum (which is certainly enough for me)?



In fact, would it be possible to unofficially use this mailing list to 
discuss proposals while we wait for a formal decision from Chaals on 
whether Geolocation can (even temporarily) be a WebAPI work item?


I don't see why not.  I have some meager thoughts on it myself, having 
spent some time reading up on it recently.



FWIW, the resources Google has to offer here aren't locked to working 
groups, they're locked to work items. So insofar as Google is concerned, 
it would make no difference if there was one group or ten, we'd have the 
same amount of resources. The list of deliverables that matters is the 
total of all the deliverables we're interested in, not the deliverables 
that a particular working group is tasked to work on.


Sure, makes sense.  In that light, it's not a burden on Google to work 
in a different WG, if that's what ends up happening.



Having said that, I personally do think it would be wiser to keep all DOM 
APIs intended for browsers in one working group. 


That was my initial impetus for proposing it in the draft charter.



The confusion we had with
two working groups (WebAPI and WAF) led to us merging them, it would be 
sad to then immediately forget the lesson we had learnt and split work up 
again.


I don't think that's the case here.  I, for one, would not want all DOM 
interface work done in the HTML WG, nor would you want it all done in 
the SVG WG.  There is a sane level of separation of concerns that 
benefits all parties.


Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Re: removeRequestHeader()

[Ian Hickson]

On Tue, 27 May 2008, Julian Reschke wrote:
> Anne van Kesteren wrote:
> > > FF3 (removing the header) demonstrates that this case (null value) either
> > > should be left unspecified, or specified with a more useful behavior.
> > 
> > Firefox demonstrates that it is not interoperable with the three other
> > browsers. It does not demonstrate anything about the need to do this
> > differently than currently specified.
> 
> Setting a header to null, and expecting the header to be sent as "null" 
> is a bug. You haven't provided any evidence of clients relying on this.
> 
> Please do not wire bad API design like this into the spec, even if it's 
> common for Javascript APIs.

I have to say, I would rather prefer it be treated as "".

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Moving forward with XHR2 and AC

[Ian Hickson]

On Tue, 27 May 2008, Jonas Sicking wrote:
> 
> What I suggest is that we prohibit the Access-Control-Policy-Path header 
> from being used on URIs that include the string "..\", in escaped or 
> unescaped form. One worry with this is if there are encodings which put 
> the '.' or '\' characters to other codepoints than 2E and 5C 
> respectively. I.e. would we need to forbid its use on URIs other than 
> ones containing
> 
> (.|%2e)(.|%2e)(\|%5c)

I could live with that.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [XHR] Dependencies in XHR

[Ian Hickson]

On Tue, 27 May 2008, Doug Schepers wrote:
> 
> It seems that there are multiple dependencies upon HTML 5.0 in the XHR 
> specification.  As Team Contact, I would like to caution against this 
> approach, as the HTML 5.0 specification is a long time from being 
> stable, and this hinders implementation (particularly for vendors who 
> sell their browsers, and must therefore market them). [...]
> 
> I believe that "origin" can be defined in the Window Object 
> specification, one of this WG's explicit deliverables.
>
> "Objects implementing the Window interface must provide an 
> XMLHttpRequest() constructor."
> 
> Again, see Window Object spec.

Um, if we're going to be moving the references away from HTML5, could we 
at least move them to specs that have a chance of actually getting 
maintained sometime this decade?


> We have discussed adding consideration for "event handler DOM attribute" 
> in the DOM3 Events spec, such that a host language can define what that 
> means in its context

That would be great, I'd love to offload this part of HTML5. Do you have a 
plan for how to resolve the dependency between event handler DOM 
attribute processing and the designMode DOM attribute? Also, please 
remember to deal with the mouseover event's quirk when doing this.

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: XHR header blacklist rationale

[Jonas Sicking]

Julian Reschke wrote:


Jonas Sicking wrote:

These should absolutely not be under control of web content.

The Referer header is used by some web servers for security checks so 
allowing this to be settable would work around that. Servers can't 
currently rely on the header being there due to some firewalls/proxies 
filtering it, however they can rely on it being true when it is there.


The User-Agent is used a lot for logging and measuring various aspects 
(OS, UA, etc) of the user base for a site. Allowing this to be 
"spoofed" by a web page would severely reduce its usefulness. You cite 
in a different mail that you want to be able to set this to work 
around servers that send different content based to different UAs 
based on this header. However if we let this header be set by web 
content then servers would not be able to rely on the User-Agent 
header and would likely start using even worse mechanisms.


Microsoft's ActiveX version of XMLHTTPRequest definitively lets clients 
set it. I know it, because it was needed to override the UA header, so 
that servers would do proper authentication instead of form-based login.


Not sure about what the native implementations do today, but I think we 
need to make sure that the XHR spec doesn't break use cases that work 
today.


I assume that by "it" you mean the User-Agent header?

Looking at the code it does indeed look like we let you set that header, 
which greatly surprises me.


My gut feeling though is that we want sites to be able to rely on the UA 
header for logging. I'm fine with breaking "use cases that work today" 
if we do it to improve security. The User-Agent header isn't strictly 
security, but it's close to.


/ Jonas

Re: Proposed errata for DOM2 Range regarding insertNode()

[Ian Hickson]

Since the idea of making it clear that insertNode() inserts the node 
inside the range even if the range is collapsed seems to have received a 
somewhat positive response, I'd like to propose the following actual 
errata text:

| DOM Level 2 Traversal and Range
| 
| range-2. 2008-06-... [clarification]. Range.insertNode
| 
| The sentence:
| 
|The node is inserted at the start boundary-point of the Range, without 
|modifying it.
| 
| Should read:
| 
|The node is inserted at the start boundary-point of the Range, without 
|modifying the start boundary-point. If the range is collapsed, the 
|offset of the Range's end boundary-point will be increased so that it 
|is before the same node or character as it was before the insertion.

This uses the language style of the spec as it stands today (we can worry 
about making the spec use RFC2119 terminology when we rewrite it later; 
doing that now too would be a big rathole IMHO).

Chaals, can we put this to the working group as a proposed errata?


On Wed, 14 May 2008, Boris Zbarsky wrote:
> > >
> > > [discussion regarding mutation event timing]
> >
> > For example regular old insertions and deletions near ranges cause 
> > changes to the range values but the spec doesn't say if this is before 
> > or after the events.
> 
> I think it's pretty clear that it should be when the actual mutation 
> occurs (so before the events for insert cases and after for removal 
> cases), but that does mean that one can't implement Range on top of DOM 
> MutationEvents.  Then again, there's no much one can implement on top of 
> them, so that's OK, I think.
> 
> > It seems that for sanity we should say it happens before, if we 
> > specify this. Should we do this as a separate errata?
> 
> I just wanted to point out that we have to be very careful in how we 
> phrase this erratum (which I agree is a possibly useful one): we 
> basically want to perform the insertion, then before firing the mutation 
> event adjust the insertion endpoint after all the nodes we just 
> inserted.  Or something.  In a UA that would fire multiple events here 
> when inserting a DocumentFragment, we might lose no matter what we try 
> to do.

I'm not sure what to do about mutation events. I think it may be wiser to 
punt on this or at least deal with it in a separate errata.


On Fri, 23 May 2008, Olli Pettay wrote:
>
> So I'm not sure the errata for this issue is actually needed.

It seems to me that everyone agrees that insertNode() was always intended 
to insert a node _into_ the range, and that the collapsed case was simply 
lost between the cracks when the DOM WG was writing the spec (much as was 
interaction with mutation events, for instance). While I agree that the 
spec could be read as saying that the node is inserted after the range 
when it is collapsed, I don't think we want that behaviour, nor that it 
was intended. Do you actually think that behaviour is preferred to the 
insertion behaviour?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [XHR] Dependencies in XHR

[Doug Schepers]

Hi, Ian-

Ian Hickson wrote (on 5/27/08 8:44 PM):

On Tue, 27 May 2008, Doug Schepers wrote:


I believe that "origin" can be defined in the Window Object 
specification, one of this WG's explicit deliverables.


"Objects implementing the Window interface must provide an 
XMLHttpRequest() constructor."


Again, see Window Object spec.


Um, if we're going to be moving the references away from HTML5, could we 
at least move them to specs that have a chance of actually getting 
maintained sometime this decade?


Obviously, we would only move references if there were a spec that 
adequately covers the necessary material.  If the Window Object spec is 
not taken up, then clearly it would be inappropriate.



We have discussed adding consideration for "event handler DOM attribute" 
in the DOM3 Events spec, such that a host language can define what that 
means in its context


That would be great, I'd love to offload this part of HTML5. Do you have a 
plan for how to resolve the dependency between event handler DOM 
attribute processing and the designMode DOM attribute? Also, please 
remember to deal with the mouseover event's quirk when doing this.


(This seems like a sarcastic and combative reply, for no good reason.)

Perhaps I misunderstood the issue.  My impression was that Anne was 
referring to the definition for the "onfoo" event handlers, as stated in 
the HTML 5.0 spec:


"Event handler DOM attributes, on setting, must set the corresponding 
event handler attribute to their new value, and on getting, must return 
whatever the current value of the corresponding event handler attribute 
is (possibly null)." [1]


We had discussed, in the DOM3 Events telcons, that we might define the 
general mechanism for "onfoo" attributes, and their relationship to 
named events, addEventListener, et al.  A host language, such as HTML or 
SVG, would define the specific event handler attributes appropriate to 
that language, and provide details about the event.  The host language 
would also cover the particulars of the quirks you mention (so, sorry, 
but you're stuck with that task).


Are you saying that this is not a useful addition to DOM3 Events?  Or 
that you don't think that this adequately covers what is needed for XHR 
(which seems only to require a definition, from my reading)?


I'm interested to hear your feedback on what would be useful for the 
DOM3 Events spec to say on the matter, beyond (on in contradiction to) 
what I have already described as the intent.



[1] http://www.w3.org/html/wg/html5/#event4

Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Re: Proposal to work on Geolocation

[Arun Ranganathan]

Ian said:

>Google would like to volunteer some resources to work on a specification 
>to provide a Geolocation API for the Web platform. Does anyone on the 
>working group think we should not work on this? If not, please consider 
>this a formal proposal from us to adopt a Geolocation API as a work item. 
>Since we need broad working group agreement to add a work item, I propose 
>that we set a deadline of June 4th for dissent, though as Chaals always 
>says, positive assent would be preferred. :-) Chaals, could you do the 
>honours of making this formal? Thanks!


Consider this positive assent from Mozilla :)  We're interested in this work 
item, and would like to see if our proposal[1] can be a clean subset of the 
Google proposal.  Mozilla also volunteers resources to work on it.

-- A*
[1] http://azarask.in/blog/post/firefox-geolocation-js-library/

Re: Proposal to work on Geolocation

[Maciej Stachowiak]

On May 27, 2008, at 3:34 PM, Charles McCathieNevile wrote:

On Tue, 27 May 2008 23:38:37 +0200, Maciej Stachowiak  
<[EMAIL PROTECTED]> wrote:



On May 27, 2008, at 2:01 PM, Doug Schepers wrote:

...
In fact, I proposed on the WebApps WG charter to add this  
deliverable. However, the Advisory Committee's review of the  
charter indicated that the Membership wants this to happen in a  
dedicated Geolocation API WG.


The W3C intends to follow through on that, and to allocate Team  
resources to this valuable technology.  We will announce something  
formal soon.

...
I could not find record of any such objection in the Advisory  
Committee mailing list archives, or any record of an official W3C  
decision on this point. As Team contact, could you please explain  
who made this decision and on what basis?


In which case I presume that someone used their ability to reply to  
the Team privately instead of being open about what they wanted.  
This disturbs me a little since it increases the resources and  
coordination required, IMHO, to do what is a pretty simple piece of  
work.


For the record, Opera would also like to see the geolocation work  
take place inside the webAPI group and is unhappy that it has been  
removed from the proposed charter for Web Apps.


And in case it wasn't clear, Apple would like to see this work item  
taken up, preferably inside this WG to save delay and coordination  
complexity.


We cannot volunteer editing resources but we would like to help with  
review and test cases.


Regards,
Maciej