Re: LC comments.

On Fri, 13 Jun 2008 11:22:29 +0200, Yves Lafon <ylafon@w3.org> wrote:
> On Thu, 12 Jun 2008, Anne van Kesteren wrote:
>> The WG might issue a primer document aimed at authors at some later  
>> stage.
>
> Well, having two documents would be even more confusing; Giving in the  
> first part of the document everything needed for authors (including  
> parts of "how it works under the hood" for those interested), and a  
> second part about all implementations requirements needed for interop  
> would be a huge win for authors.

I think authors are better of with a tutorial personally. I also don't see  
the specification changing so significantly this late in the game.


>> Just see it as a magical string the user agent has to reject. A note  
>> has been added to clarify why it is mentioned:
>>
>> http://dev.w3.org/2006/webapi/XMLHttpRequest/#open
>
> Well, magic is quite scary, I'd rather have a statement explaining  
> roughly what TRACK is about (something non standard, not well  
> documented, and quite similar in functionnality to TRACE).

The specification says "Note: TRACK poses a security issue to legacy  
server deployments." What is not good about that?


>>> <<
>>> Also for security reasons, these steps should be terminated if the  
>>> start of the header argument case-insensitively matches Proxy- or Sec-.
>>>>>
>>> It would forbid other spec to do something fancy with Proxy-* or Sec-*  
>>> headers, why ?
>>
>> This allows the introduction of headers in the future that can't be set  
>> by XMLHttpRequest.
>
> Yes, but why ?

Because there have been cases where this could've been useful and going  
forward we might identify more of these cases. (For instance, the latest  
was an Origin header that would give the origin of the request (origin is  
a scheme, domain, port tuple).


>>> Why not linking to those requirements ?
>>
>> Because HTTP is to be fully read and understood anyway when  
>> implementing XMLHttpRequest.
>
> Then you don't need to restate what is already in rfc2616 and can  
> completely remove the last paragraph (but you know it will be dangerous  
> for interop, as most people won't read the whole tree of linked  
> documents)
> At least a link would help people find those requirements, no extra text  
> needed.

There's already a link at the end of the document to RFC 2616. Since the  
IETF uses plain text for specifications there's not really a way to link  
to those definitions directly. (Yes, with the new plain text fragment  
identifier thingy this might be resolved, but that's not deployed in any  
way.)


>>> <<
>>> In case of DNS errors, or other type of network errors, run the  
>>> following set of steps. This does not include HTTP responses that  
>>> indicate some type of error, such as HTTP status code 410.
>>> [...]
>>> >>
>>> Some request may be retried, like GET, especially if the targeted web  
>>> site resolves in a set of IP addresses and some of them may be down.  
>>> It is unclear that the implementation will try its best to process the  
>>> request, by retrying when needed, or if it is forbidden.
>>
>> In case it is not an error it should just do what HTTP specifies.
>
> Well, that's not how I read the list here. I see "try to connect, if it  
> fails -> exit in error".

Could you give me a section number or quote from RFC 2616 you think this  
conflicts with?


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Friday, 13 June 2008 12:11:11 UTC