On Fri, 13 Jun 2008 11:22:29 +0200, Yves Lafon <[EMAIL PROTECTED]> 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/>
