Re: [xmlhttprequest] getResponseHeader() for invalid header

[Anne van Kesteren]

On Sat, 08 Mar 2008 00:42:47 +0100, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:

On Mar 7, 2008, at 3:12 PM, Anne van Kesteren wrote:
I think three out of four return null for a non-existent header (IE  
being the exception, iirc). Firefox and an internal version of Opera  
also return null for invalid headers. (Although for Firefox it seems to  
differ on based on whether the request has happened already or  
something...)


In that case I think it makes sense to use null for both missing and  
invalid headers.


Agreed. Fixed in both XMLHttpRequest specs and also in the test suite.


--
Anne van Kesteren

Re: XHR setRequestHeader("connection", "close") is bogusly rejected

[Maciej Stachowiak]

On Mar 7, 2008, at 3:02 PM, Morgan L wrote:


Ah, that make sense to me.  I think the current text
has caused major browser engines to "mistakenly" stop
supporting connection: close.  It is easy to blindly
implement whatever the "standards" say :-)

I think it would help if a caveat were added along the
lines of what you have written here.  I think the
"connection: close" example should be used to
demonstrate why it might be wise for a user-agent to
customize what request headers it rejects.

I'm not sure that section 13.5.2 implies that
"connection: close" can be wrong.  It is true that an
XHR users cannot assume that the origin server will
see the "connection: close" header, but it is still
always the case that the UA would see it.  And, in the
example that I provided, the goal is to tell the UA
that it does not need to count this request against
the max-persistent-connections-per-host limit.At
least, I can't see how allowing XHR users to specify
"connection: close" can be regarded as harmful.

Thoughts?


If the problem we are trying to solve is preventing potentially long- 
lived requests from blowing out the connection limit I think it would  
be better to either:


1) Add an explicit XHR property that indicates this request may be  
long-lived - this would not only bypass the connection limit but would  
also indicate to the UA that it should not pipeline other requests on  
the same connection, if it supports pipelining.


2) Never count XHR-initiated http requests towards the per-server  
connection limit.


Given that IE has increased their per-server connection limit to 6,  
and since the HTTP working group is considering dropping the  
connection limit as a formal spec requirement, I would probably advise  
#2 for WebKit and have commented to that effect in the bug you cited.  
From the spec point of view, I think #1 makes more sense since it may  
be inappropriate to require #2 (thoughts from other implementors  
welcome).


Requiring UAs to recognize "Connection: close" as a hint that the  
connection may be long-lived and should not count towards the limit is  
also possible as a variant of option 1. But I am not sure they should  
be required to also pass the header to the origin server. This does  
not seem necessary for the goal of bypassing the connection limit on  
the UA side. And it seems that an explicit XHR property for this would  
be more clear.


Regards,
Maciej

Re: [XHR2] Editorial:

[Anne van Kesteren]

On Thu, 28 Feb 2008 04:24:30 +0100, Elliotte Harold  
<[EMAIL PROTECTED]> wrote:
When the s teps for the send() method say to make upload progress  
notifications user agents must, if the request entity body is not empty  
and async is


"s teps" --> "steps"


Fixed.


Also you might wish to change your mailto link so the [XHR2] at the  
start of the subject line is automatic.


Fixed, thanks for your comments!


You can review the changes in:

  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/


--
Anne van Kesteren

Re: [xmlhttprequest] getResponseHeader() for invalid header

[Maciej Stachowiak]

On Mar 7, 2008, at 3:12 PM, Anne van Kesteren wrote:

On Sat, 08 Mar 2008 00:06:02 +0100, Maciej Stachowiak  
<[EMAIL PROTECTED]> wrote:

On Mar 7, 2008, at 2:59 PM, Anne van Kesteren wrote:
Currently getResponseHeader() returns the empty string for invalid  
header names.  Would people object if I changed that to returning  
null instead (basically making it equivalent to headers not part  
of the response)? Thanks.


What do current implementations do for these cases?


I think three out of four return null for a non-existent header (IE  
being the exception, iirc). Firefox and an internal version of Opera  
also return null for invalid headers. (Although for Firefox it seems  
to differ on based on whether the request has happened already or  
something...)


In that case I think it makes sense to use null for both missing and  
invalid headers.


 - Maciej

Re: XHR setRequestHeader("connection", "close") is bogusly rejected

[Jonas Sicking]

Morgan L wrote:

Hi, I'm writing about what appears to be an error in
the XHR TR.

In section 2 of http://www.w3.org/TR/XMLHttpRequest/,
it says that setRequestHeader should reject the
connection header.

However, there are web apps in existence (e.g., Gmail)
that set the "connection: close" header to inform the
user-agent that the HTTP transaction is going to take
a long time.  (This is also informative for the
server.)  This allows a user-agent to not count this
connection against the RFC 2616 recommended maximum of
2 persistent connections per host.

So, it seems to me that the arguments
setRequestHeader("connection", "close") should be
allowed.

More details in this WebKit bug:
http://bugs.webkit.org/show_bug.cgi?id=17682

It looks like recent versions of WebKit and Gecko
block the "connection" request header per this TR. 
However, Firefox 2 does not.


We do block, but not because of this TR. IIRC there are security issues 
with other values for connection, though I don't specifically remember 
what they are. However setting something like "connection: keep-alive" 
when the browser is not expecting that could have bad effects on other 
connections to that server.


/ Jonas

Re: [xmlhttprequest] getResponseHeader() for invalid header

[Anne van Kesteren]

On Sat, 08 Mar 2008 00:06:02 +0100, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:

On Mar 7, 2008, at 2:59 PM, Anne van Kesteren wrote:
Currently getResponseHeader() returns the empty string for invalid  
header names.  Would people object if I changed that to returning null  
instead (basically making it equivalent to headers not part of the  
response)? Thanks.


What do current implementations do for these cases?


I think three out of four return null for a non-existent header (IE being  
the exception, iirc). Firefox and an internal version of Opera also return  
null for invalid headers. (Although for Firefox it seems to differ on  
based on whether the request has happened already or something...)



--
Anne van Kesteren

Re: [xmlhttprequest] getResponseHeader() for invalid header

[Maciej Stachowiak]

On Mar 7, 2008, at 2:59 PM, Anne van Kesteren wrote:



Currently getResponseHeader() returns the empty string for invalid  
header names.  Would people object if I changed that to returning  
null instead (basically making it equivalent to headers not part of  
the response)? Thanks.


What do current implementations do for these cases?

 - Maciej

Re: XHR setRequestHeader("connection", "close") is bogusly rejected

[Morgan L]

--- Bjoern Hoehrmann <[EMAIL PROTECTED]> wrote:

> * Morgan L wrote:
> >In section 2 of
> http://www.w3.org/TR/XMLHttpRequest/,
> >it says that setRequestHeader should reject the
> >connection header.
> 
> The purpose of these restrictions is to remind
> implementers that the
> user agent has to control certain headers for
> protocol integrity or
> other reasons, in other words, implementations
> should not blindy pass
> to the server whatever value a script might have set
> there.
> 
> It should be perfectly permissable if the
> implementation instead of
> ignoring the attempt at setting some value takes the
> attempt under
> advisement when making its own decisions what to set
> the header to,
> in other words, the browser might well list close
> among the tokens
> after a script tried to set the header.
> 
> I agree the current text does not convery this very
> well, do you have
> a suggestion how to editorially improve it? We can't
> simply "allow"
> this particular case as simply sending "Connection:
> close" can be wrong
> in many cases (see e.g. RFC 2616, section 13.5.1).

Ah, that make sense to me.  I think the current text
has caused major browser engines to "mistakenly" stop
supporting connection: close.  It is easy to blindly
implement whatever the "standards" say :-)

I think it would help if a caveat were added along the
lines of what you have written here.  I think the
"connection: close" example should be used to
demonstrate why it might be wise for a user-agent to
customize what request headers it rejects.

I'm not sure that section 13.5.2 implies that
"connection: close" can be wrong.  It is true that an
XHR users cannot assume that the origin server will
see the "connection: close" header, but it is still
always the case that the UA would see it.  And, in the
example that I provided, the goal is to tell the UA
that it does not need to count this request against
the max-persistent-connections-per-host limit.At
least, I can't see how allowing XHR users to specify
"connection: close" can be regarded as harmful.

Thoughts?

--morgan


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: Geolocation API proposal

[Maciej Stachowiak]

On Mar 7, 2008, at 2:38 AM, Doug Schepers wrote:



Hi, Aaron-

Aaron Boodman wrote (on 3/6/08 8:55 PM):

I work on Google Gears team. If you're not familiar with what Gears
is, you can learn more here: http://code.google.com/apis/gears.
We've been working on an API that will allow an application to obtain
(with permission) the user's current location. I posted this to the
WhatWG mailing list, but it was suggested that this might be a more
appropriate place.
Anyway, here's our current design:
http://code.google.com/p/google-gears/wiki/LocationAPI
We think there's a lot of potential for interesting applications with
a API like this. Some examples would be recommendations for nearby
restaurants, turn by turn directions, or city walking tours.
Are there any other vendors interested in implementing something like
this? If so, we'd like to work together to come up with a standard.
Otherwise, I'll just put this out there for comment for the time
being. We'd appreciate any feedback on the design, one way or the
other.


This is interesting stuff, and I agree it is very useful to have.

There is already some activity happening in this area, in the  
Ubiquitous Web Applications Working Group (UWA or UbiWeb). [1]  It's  
obviously a hot topic, and one I personally hope can be specified  
and deployed quickly (since we're already about 15 years behind  
Japan in this stuff ^_^ ).


I think you hit the nail regarding vendors... that's a crucial next  
step.


I'm happy to facilitate bringing your insight in this area to W3C,  
and I'm sure we can find the best way to move this forward, and get  
involvement from other vendors.  Feel free to drop me a line  
offlist, and I can do a bit more research and point you in the right  
direction.


[1] http://www.w3.org/2007/uwa/


I am much more interested in Aaron's proposal than in DCCI (comments  
forthcoming).


Regards,
Maciej

[xmlhttprequest] getResponseHeader() for invalid header

[Anne van Kesteren]

Currently getResponseHeader() returns the empty string for invalid header  
names.  Would people object if I changed that to returning null instead  
(basically making it equivalent to headers not part of the response)?  
Thanks.



--
Anne van Kesteren

Re: Geolocation API proposal

[Scott Shattuck]

Not sure if this is relevant yet, but it's another data point:

http://fireeagle.yahoo.net/


On Mar 7, 2008, at 1:11 AM, Robert Sayre wrote:



On Thu, Mar 6, 2008 at 5:55 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:


I posted this to the WhatWG mailing list, but it was suggested that  
this

might be a more appropriate place.


Surely WhatWG would be more convenient? I mean, the editor can just
rubber stamp it for you...

--

Robert Sayre

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

Re: [Elemement Traversal LC] why is the interface implemented as attributes in ECMASCRIPT?

[Simon Pieters]

On Fri, 07 Mar 2008 09:48:30 +0100, Slim Amamou <[EMAIL PROTECTED]>  
wrote:



hi,
the ElementTraversal interface is bound to readonly attributes in
ecmascript, whereas it is bound to methods in java.
why?

it would be more convenient if it was bound to methods in ecmascript  
either.

i can think of two arguments for this :
- the bindings will be more consistent (so that you don't have
"getChildElementCount" and "childElementCount" representing the same
binding)
- i can make a quick implementation in javascript


FWIW, I made a javascript implementation a while ago:

   http://simon.html5.org/sandbox/js/elementtraversal.js


Cheers,
--
Simon Pieters
Opera Software

Re: [Elemement Traversal LC] why is the interface implemented as attributes in ECMASCRIPT?

[liorean]

On 07/03/2008, Slim Amamou <[EMAIL PROTECTED]> wrote:
> hi,
> the ElementTraversal interface is bound to readonly attributes in
> ecmascript, whereas it is bound to methods in java.
> why?

Because having things like this as as properties is normal the
ECMAScript way, but having getter and setter functions is the normal
Java way.

> it would be more convenient if it was bound to methods in ecmascript either.
> i can think of two arguments for this :
>  - the bindings will be more consistent (so that you don't have
> "getChildElementCount" and "childElementCount" representing the same
> binding)

Having getter and setter functions using method syntax is a distinctly
foreign way of doing this in JavaScript. Plus, these properties
analogously match the way it's done for the node traversal bindings in
our earlier DOM versions. And thirdly, those would be two different
bindings to the same functionality, not the same binding.


Really, I think the DOM is too Java-istic from an ECMAScript
perspective already, and intra-language bindings coherency is more
important than inter-language bindings coherency.
-- 
David "liorean" Andersson

More on DOM 3 Test Suite Effort

[Carmelo Montanez]

All:

I am working on:

1) XML Catalog to define metadata for DOM 3 Test Suite
2) Stylesheet to report the metada in a human readable form
3) A Schema to make sure file is valid according to some rules (some I made
up and some we will decide soon).
3) Release Notes Files
4) Readme file.
5) Working on defining tests on XML format and transform them into a
Java Script DOM Level 3 test.

I can either mail these documents out to the list or post them somewhere (will
write privileges, Item number 5 below will take a while 
longer)).  Please advise
on the "somewhere".  I will do a gargantuan effort to get something 
out today, but

time is catching up with me.

A lot of it is based on the approach we took for the XML Query 
Working Group with

some variations of course.

Cheers
Carmelo 

Re: Geolocation API proposal

[Doug Schepers]

Hi, Aaron-

Aaron Boodman wrote (on 3/6/08 8:55 PM):


I work on Google Gears team. If you're not familiar with what Gears
is, you can learn more here: http://code.google.com/apis/gears.

We've been working on an API that will allow an application to obtain
(with permission) the user's current location. I posted this to the
WhatWG mailing list, but it was suggested that this might be a more
appropriate place.

Anyway, here's our current design:

http://code.google.com/p/google-gears/wiki/LocationAPI

We think there's a lot of potential for interesting applications with
a API like this. Some examples would be recommendations for nearby
restaurants, turn by turn directions, or city walking tours.

Are there any other vendors interested in implementing something like
this? If so, we'd like to work together to come up with a standard.
Otherwise, I'll just put this out there for comment for the time
being. We'd appreciate any feedback on the design, one way or the
other.


This is interesting stuff, and I agree it is very useful to have.

There is already some activity happening in this area, in the Ubiquitous 
Web Applications Working Group (UWA or UbiWeb). [1]  It's obviously a 
hot topic, and one I personally hope can be specified and deployed 
quickly (since we're already about 15 years behind Japan in this stuff 
^_^ ).


I think you hit the nail regarding vendors... that's a crucial next step.

I'm happy to facilitate bringing your insight in this area to W3C, and 
I'm sure we can find the best way to move this forward, and get 
involvement from other vendors.  Feel free to drop me a line offlist, 
and I can do a bit more research and point you in the right direction.


[1] http://www.w3.org/2007/uwa/

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

Re: XBL 2.0 implementation made available for major browsers

[laurent]

Sergey Ilinsky wrote:

I thought you got it, if not, see the goals of the implementation:
- draw attention to XBL 2.0, the only "extension point" for DHTML today
- let folk experiment with the technology, many people still do not get 
the sense of technology




Yes, I saw it of course. I'm a big fan of XBL, I'm working with XBL for 
years with the Mozilla framework. And my dream is to see XBL2 
implemented in all browsers :-)


So I think such javascript implementation is a good thing because people 
can experiment XBL, and then, if they like it, can force browser editor 
to implement a full native XBL2 support :-)


(Perhaps it will be implemented in Gecko 2 
https://bugzilla.mozilla.org/show_bug.cgi?id=374737 )


Laurent Jouanneau

Re: XBL 2.0 implementation made available for major browsers

[Sergey Ilinsky]

Laurent et al,

I thank you very much for the feedback provided and the attention payed.

Yes, as many of you guessed, the shadow content (the one coming from XBL 
template) of course doesn't become anonymous while is inserted into the hosting 
language DOM. Yes, this IS a problem, since the specification clearly says on 
where it should go (anonymous content is of course one of the key features of 
the language). However when used carefully even that "ugly" trick can be worth 
of the other benefits. (There is many use cases that do not even require 
templating, right?)

I thought you got it, if not, see the goals of the implementation:
- draw attention to XBL 2.0, the only "extension point" for DHTML today
- let folk experiment with the technology, many people still do not get the 
sense of technology

And yet, do not forget we all leave in a real world, world of coming out IE8 
locked on DOM-0 etc.

Sergey Ilinsky/




laurent <[EMAIL PROTECTED]> wrote: Hi Sergey,

This is a great work, congratulation !

However, your implementation of XBL2 is not full : nodes added from an 
XBL are not anonymous, and this is a big issue. Because many DOM 
properties and methods don't return expected results. For example 
mynode.firstChild should not return a node added by XBL.

http://www.w3.org/TR/2007/CR-xbl-20070316/#shadow5

But unfortunately, I think you couldn't fix this issue, unless browser 
provide API to create anonymous nodes... (In Gecko, there is a such API, 
but it's an internal API).


Laurent

Sergey Ilinsky wrote:
> Hi, WebAPI fans
> 
> There have been not much activity in the group since a while, so I 
> thought I could bring something for consideration.
> 
> On my spare time I've implemented XBL 2.0 in JavaScript, a tiny (8k 
> gzipped) library that brings support for the technology to all major 
> web-browsers. The project is hosted on Google Code 
> http://code.google.com/p/xbl/ , if you are interested check it out.
> The implementation supports most of XBL 2.0 features with except for 
> three principal - processing instruction  (you still have an 
> option to use Behavioral Extensions to CSS), 
> xbl-bound/xbl-bindings-are-ready events and xbl:attr attribute. A 
> detailed breakdown on features can be found at 
> http://code.google.com/p/xbl/wiki/Features There is also a pair of 
> examples as well as tests demonstrating multiple aspects of the 
> implementation.
> 
> Get your bindings bound!
> 
> Sergey Ilinsky/





   
-
 Rise to the challenge for Sport Relief with Yahoo! for Good

Re: XBL 2.0 implementation made available for major browsers

[João Eiras]

For Opera you can use a mix of css content rules with data urls, to
load content inside an element, and keeping it hidden from the dom. I
don't know however, if it'll fit your usecases.

2008/3/7, laurent <[EMAIL PROTECTED]>:
>
>  Hi Sergey,
>
>  This is a great work, congratulation !
>
>  However, your implementation of XBL2 is not full : nodes added from an
>  XBL are not anonymous, and this is a big issue. Because many DOM
>  properties and methods don't return expected results. For example
>  mynode.firstChild should not return a node added by XBL.
>
>  http://www.w3.org/TR/2007/CR-xbl-20070316/#shadow5
>
>  But unfortunately, I think you couldn't fix this issue, unless browser
>  provide API to create anonymous nodes... (In Gecko, there is a such API,
>  but it's an internal API).
>
>
>
>  Laurent
>
>
>  Sergey Ilinsky wrote:
>  > Hi, WebAPI fans
>  >
>  > There have been not much activity in the group since a while, so I
>  > thought I could bring something for consideration.
>  >
>  > On my spare time I've implemented XBL 2.0 in JavaScript, a tiny (8k
>  > gzipped) library that brings support for the technology to all major
>  > web-browsers. The project is hosted on Google Code
>  > http://code.google.com/p/xbl/ , if you are interested check it out.
>  > The implementation supports most of XBL 2.0 features with except for
>  > three principal - processing instruction  (you still have an
>  > option to use Behavioral Extensions to CSS),
>  > xbl-bound/xbl-bindings-are-ready events and xbl:attr attribute. A
>  > detailed breakdown on features can be found at
>  > http://code.google.com/p/xbl/wiki/Features There is also a pair of
>  > examples as well as tests demonstrating multiple aspects of the
>  > implementation.
>  >
>  > Get your bindings bound!
>  >
>  > Sergey Ilinsky/
>
>
>
>
>

Re: XBL 2.0 implementation made available for major browsers

[laurent]

Hi Sergey,

This is a great work, congratulation !

However, your implementation of XBL2 is not full : nodes added from an 
XBL are not anonymous, and this is a big issue. Because many DOM 
properties and methods don't return expected results. For example 
mynode.firstChild should not return a node added by XBL.


http://www.w3.org/TR/2007/CR-xbl-20070316/#shadow5

But unfortunately, I think you couldn't fix this issue, unless browser 
provide API to create anonymous nodes... (In Gecko, there is a such API, 
but it's an internal API).



Laurent

Sergey Ilinsky wrote:

Hi, WebAPI fans

There have been not much activity in the group since a while, so I 
thought I could bring something for consideration.


On my spare time I've implemented XBL 2.0 in JavaScript, a tiny (8k 
gzipped) library that brings support for the technology to all major 
web-browsers. The project is hosted on Google Code 
http://code.google.com/p/xbl/ , if you are interested check it out.
The implementation supports most of XBL 2.0 features with except for 
three principal - processing instruction  (you still have an 
option to use Behavioral Extensions to CSS), 
xbl-bound/xbl-bindings-are-ready events and xbl:attr attribute. A 
detailed breakdown on features can be found at 
http://code.google.com/p/xbl/wiki/Features There is also a pair of 
examples as well as tests demonstrating multiple aspects of the 
implementation.


Get your bindings bound!

Sergey Ilinsky/

[Elemement Traversal LC] why is the interface implemented as attributes in ECMASCRIPT?

[Slim Amamou]

hi,
the ElementTraversal interface is bound to readonly attributes in
ecmascript, whereas it is bound to methods in java.
why?

it would be more convenient if it was bound to methods in ecmascript either.
i can think of two arguments for this :
- the bindings will be more consistent (so that you don't have
"getChildElementCount" and "childElementCount" representing the same
binding)
- i can make a quick implementation in javascript

-- 
Slim Amamou
http://NoMemorySpace.wordpress.com

Re: Geolocation API proposal

[Robert Sayre]

On Thu, Mar 6, 2008 at 5:55 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:
>
> I posted this to the WhatWG mailing list, but it was suggested that this
> might be a more appropriate place.

Surely WhatWG would be more convenient? I mean, the editor can just
rubber stamp it for you...

-- 

Robert Sayre

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