Julian Reschke wrote:
b) Algorithms: the spec uses a method to describe algorithms that IMHO
is extremely hard to read (see for instance send() method). This maybe
good for implementors, but seems to be bad for everybody else.
Minimally, the lists should be structured for better readability.
Could you elaborate on what kind of change you envision? I'm not
surehow they are not structured right now.
An example would be steps 8..11 in the description of open():
- these steps deal with credentials, and the whole list would be more
readable if each group of steps that belong together would me structured
that way;
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.
c) Structure: It would be nice if Section 4 had more structure. Right
now 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.
Yes, as stated it must be a subset that matches what XMLHttpRequest
requires 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
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.
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 HttpOnly
cookies I rather not remove that. I think it will be clear enough for
people 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
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.
"If the user argument was not omitted and is not null let stored
userbe user encoded using the encoding specified in the relevant
authentication scheme or UTF-8 if the scheme fails to specify an
encoding."
Why is XHR talking about the encoding here? Is "stored user" a
stringor a byte array?
(same for password)
They're a string (in the API).
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.
"If the value argument is null terminate these steps. (Do not raise an
exception.)."
This makes it impossible to set empty headers, which are allowed in
HTTP. Even worse, it silently fails.
Empty headers can be set using the empty string, no? Not raising an
exception is consistent with implementations and I don't think
itmatters much as it doesn't have any effect.
Sorry, was reading one thing, but thinking about something else.
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.
"Serialize data into a namespace well-formed XML document and encoded
using 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.
"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 has
initialized 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
"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 (not
Set-Cookie2) spec as well (RFC2109).
I believe it used to do that and it was pointed out that that
specification is not useful in practice and would actually do more harm
than 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.
"// 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.
"status of type unsigned short, readonly
On getting, if available, it must return the HTTP status code sent by
the server (typically 200 for a successful request). Otherwise, if not
available, 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.
"statusText of type DOMString, readonly
On getting, if available, it must return the HTTP status textsent
by the server (appears after the status code). Otherwise, if not
available, the user agent must raise an INVALID_STATE_ERR exception."
Really? It seems to me that if somebody really implements this,clients
are likely to break. Why not allow an empty string here?
This is what clients have implemented as far as I can tell. Though the
HTTP status text could be the empty string, if that's what you mean...
Does the "if not available" apply to any of the existing
implementations? Why would it be "not available"? Please clarify.
Added "(request is not initiated for instance)".
All requirements from HTTP are taken over unless explicitly stated so I
don'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.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
