Anne van Kesteren wrote:
Since this is the second Last Call and credentials are already following
each other (and the same for other similar steps) I've decided not to
change this.
Unfortunately.
c) Structure: It would be nice if Section 4 had more structure.
Rightnow it's ugly to navigate and refer to.
This is better in XMLHttpRequest Level 2. I rather not revise
thatentire section editorially as it might introduce new errors.
But then, it makes a comparison with XHR2 harder. Please reconsider.
Given that XMLHttpRequest Level 2 has more changes than just this in
terms of structure I don't think it will help that much.
At this point, I'm not sure why we're bothering with XHR1 at all. It is
*not* what the current implementations do anyway.
Yes, as stated it must be a subset that matches what
XMLHttpRequestrequires from the eventing and core specifications.
Then it would be clearer if it said "the subset" instead of "some
subset".
Changed:
http://dev.w3.org/2006/webapi/XMLHttpRequest/#dependencies
Thanks.
Well, if we're talking about URIs (and I think we do), then we need to
refer to RFC3986 grammar and comparison rules.
Ok, referenced RFC3986 as well.
That's not sufficient, and not what I asked for. Please make up your
mind whether it's a URI or a IRI, and then cite accordingly.
Besides that: this may be a non-optimal example unless we can point
toa definition of "HttpOnly cookies". Can we?
I don't believe we can, but since this was put in mostly for
HttpOnlycookies I rather not remove that. I think it will be clear
enough forpeople reading the document.
So why don't we refer to the specification for httpOnly? Do you consider
it a problem that it's a Microsoft document?
I added a pointer to http://msdn.microsoft.com/en-us/library/ms533046.aspx
Thanks.
As TRACK doesn't seem to be documented anywhere, and not implemented in
current IIS versions anymore, I'd really like to see this made a foot
node. The way it's written now is just totally confusing to every reader
who doesn't know the full story around it.
I added a note.
I'd prefer it to be moved somewhere else, but at least it's an improvement.
When they are a string, then taking about character encoding doesn't
make any sense here.
Actually, since you need to encode them for the request it does.
But that totally depends on the authentication scheme. I think you're
confusing layers here.
Thinking of it, could you please add a clarification that setting to an
empty string is legal, and MUST NOT be ignored? I recall that
Microsoft's original XHR (ActiveX) implementation got that wrong, not
setting the header at all.
I added a note to that effect as it is already normatively required.
Thanks. It currently says:
"Note: The empty string is legal."
Maybe you could add "and represent an empty header value"?
"Serialize data into a namespace well-formed XML document and
encodedusing the encoding given by data.inputEncoding, when not
null, orUTF-8 otherwise. Or, if this fails because the Document
cannot beserialized act as if data is null."
Does anybody rely on that? I would be very suprised.
I don't know, but it seems safest to not require changes here for
compatibility.
Sounds like something that should be tested. Silent data loss is a bad
thing, and I really don't believe that any existing content relies on that.
"If no Content-Type header has been set using
setRequestHeader()append a Content-Type header to the list of
request headers with avalue of application/xml;charset=charset
where charset is theencoding used to encode the document."
This will result in an invalid Content-Type header if the UA
hasinitialized the headers with a default (which I think the
speccurrently allows; and at least one UA was reported to do). See
commentabove about header handling.
Rephrased.
Pointer?
http://dev.w3.org/2006/webapi/XMLHttpRequest/#send
So is it legal for implementations to populate certain headers upon
object creation?
"If the user agent supports HTTP State Management it should
persist,discard and send cookies (as received in the Set-Cookie
andSet-Cookie2 response headers, and sent in the Cookie header)
asapplicable. [RFC2965]"
This should probably include a reference to the Set-Cookie
(notSet-Cookie2) spec as well (RFC2109).
I believe it used to do that and it was pointed out that
thatspecification is not useful in practice and would actually do
more harmthan good. I'm not really sure what to do here.
Well, the one that is not used in practice is RFC2965, not RFC2109. That
being said, you probably need to reference both.
Ok done.
Thanks.
"// The following script:
var client = new XMLHttpRequest();
client.open("GET", "test.txt", true);
client.send();
client.onreadystatechange = function() {
if(this.readyState == 3) {
print(this.getAllResponseHeaders());
}
}
// ...should output something similar to the following text:
Date: Sun, 24 Oct 2004 04:58:38 GMT
Server: Apache/1.3.31 (Unix)
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain; charset=utf-8"
I think examples like this would be more readable (and take
lessspace) when using the syncr. mode.
I would like to avoid encouraging authors to use the synchronous API.
Disagreed. I think readability and compactness is more important here.
I disagree. It would also change the example as then the header
information would only be made available after all data has been
downloaded rather than when the header information is available.
How is this relevant for demonstrating the output format for
getAllResponseHeaders()?
"status of type unsigned short, readonly
On getting, if available, it must return the HTTP status code sent
bythe server (typically 200 for a successful request). Otherwise, if
notavailable, the user agent must raise an INVALID_STATE_ERR
exception."
This may be incorrect when the UA caches (304 vs 200).
That's why it says typically.
Hm, no.
When the UA caches, and the server sent 304, the client will potentially
see a 200. This would contradict what *this* paragraph says.
I fixed this by saying that in case of user agent conditional requests
the user agent must act as if the server gave a 200 response in case of
a 304 response.
That's better, although still a bit confusing.
All requirements from HTTP are taken over unless explicitly stated so
Idon't think this is needed.
Well, the spec repeats lots of things specified somewhere else already.
The warning from the HTTP spec is relevant and should appear here, as
XHR is related to UAs, and existing UAs are known to ignore this
security consideration.
In that case I'd be even more hesitant to repeat it in XMLHttpRequest as
it seems like something HTTP should try to address one way or another.
Well, it is addressed in HTTP.
BR, Julian
