RE: XHR LC comments

Comment Inline.

> -----Original Message-----
> From: public-webapi-request@w3.org [mailto:public-webapi-request@w3.org]
> On Behalf Of Julian Reschke
> Sent: Friday, May 16, 2008 4:14 AM
> To: Anne van Kesteren
> Cc: Web API WG (public)
> Subject: Re: XHR LC comments
>
>
> 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.
[Sunava Dutta] I'm sorry, this statement is concerning and I'd like to understand it better. We haven’t had a chance to run the latest test suite yet but expect the test suite to be compliant with at least two existing implementations. Do you mean the XHR 1 draft is not interoperable with existing implementations?

>
> >>> 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
>
>

Received on Friday, 16 May 2008 20:53:34 UTC