On Fri, 21 Apr 2006 18:29:06 +0200, Mark Nottingham <[EMAIL PROTECTED]>
wrote:
See section 7.2.1; something like
"XHR operates across entity bodies, as defined by [RFC2616, section
7.2.1]; that is, transfer-encodings are applied to request bodies
submitted to send(), as well as response bodes made available."
I used "entity body" for responseText like:
<p>If the <code><term>readyState</term></code> attribute has a value
other
than 3 (Receiving) or 4 (Loaded), it MUST be the empty string.
Otherwise,
it MUST be the fragment of the entity body received so far (when
<code><term>readyState</term></code> is 3 (Receiving)) or the entity
body
(when <code><term>readyState</term></code> is 4 (Loaded)), interpreted
using the character encoding specified in the response, or UTF-8 if no
character encoding was specified. Invalid bytes MUST be converted to
U+FFFD REPLACEMENT CHARACTER.</p>
I made the reference to RFC 2616 in a separate definition section.
Ack. BTW, the issues list isn't obviously linked from the WG's home page.
It's right under Documents at http://www.w3.org/2006/webapi/ (first hit
for "issue") or did you mean the Member home page?
WRT URIs, what should happen when I pass it a URI with a fragment
identifier?
Do you perhaps know what implementations do?
I can't imagine that they'd do much, but I'll test and report back.
Assuming they don't, it might be good to say something to the effect
that fragment identifiers either
a) aren't allowed
b) might not be supported
Please e-mail your findings in a separate e-mail. Based on the results we
should probably be able to come up with some reasonable requirements on
UAs and authors...
When talking about redirects, it would be really nice to remind
implementers (probably non-normatively) that HTTP has requirements
about method preservation and getting approval for the user for the
various codes; see http://www.mnot.net/javascript/xmlhttprequest/
Suggestions for text? I also wonder what kind of implications it would
have for implementations given that currently most seem to ignore it.
"Implementers should note that HTTP places requirements on
implementations regarding the preservation of the request method during
redirects, and also requires users to be notified of certain kinds of
automatic redirections."
<p>If the response is an HTTP redirect (status code 301, 302, 303 or
307),
then it MUST be transparently followed (unless it violates security or
infinite loop precautions). Note that HTTP [RFC2616] places requirements
on UAs regarding the preservation of the request method during
redirects,
and also requires users to be notified of certain kinds of automatic
redirections. Any other error (including a 401) MUST cause the object to
WRT how it affects implementers, I think that's a question of whether
the WG intends to test the requirements it inherits from HTTP (and other
specs) during the CR phase.
Guess so.
Content-coding is a property of the content (entity, representation,
whatever) itself -- just like content-type and content-language -- and
automatically handling it breaks layering (which is OK, as long as you
do it explicitly). This means that if decoding is handled
automagically, the appropriate part of the Content-Encoding header
should probably be stripped, so the app doesn't get confused.
What do you mean?
In HTTP, Content-* headers are entity headers -- they describe
properties of the content explicitly. As such, they're not transparently
handled by the implementations; if I send an entity and it's got a gzip
encoding, I expect the guy on the other side to get a gzip encoding as
well.
All that said, many people find it convenient for the implementation to
handle content-encoding automatically.
I think the implication of this is that *if* the WG decides that
content-encoding can be handled by the implementation automatically,
there should be some control offered to the user over whether or not it
happens.
The real trick for the WG might be in deciding what the default of that
control is.
Thanks, this makes it more clear. Are you willing to raise another issue
or should I do it? If you have more fancy tests available by the way for
this, they are welcome :-) The default probably has to be based on what
currently works.
[...]
"Otherwise, the nominated request header field value MUST be set to
value. If the nominated request header field already has a value, the
new value SHOULD be combined with the existing value, as specified by
[RFC2616 Section 4.2]. Implementations MAY replace an existing value
(instead of combining it with the new value) if the nominated request
header field value is not specified as a comma-separated list."
Use this text, thanks!
Say something to the effect that if the UA has a cache, it MUST honour
Cache-Control request headers sent with setRequestHeader(). This
allows the application to control the cache.
So we need more text besides "In particular, UAs MUST NOT automatically
set the <code>Cache-Control</code> or <code>Pragma</code> headers to
defeat caching [RFC2616]."?
Yes. Something like "UAs that implement a cache should honour request
cache-control headers." Note the lower-case SHOULD; HTTP already
requires them to be honoured.
Based on my testing, implementations don't do this today. It would be
very good if they do; as it is, developers don't have any control of the
local cache.
Perhaps we can cover this in the testsuite?
[...]
The text reads as if persistent connection support is required, when
HTTP does not require it. It also normatively re-states the requirements
of HTTP, which isn't good specification practice.
Well, another way to set these headers is letting the author do it. So I
can see why there's a requirement on UAs here from that perspective...
It should just be:
"UAs MUST NOT allow the Connection, Keep-Alive and Content-Length
headers to be overridden."
Using the same logic, the requirement about the Host header should be
"UAs MUST NOT allow the Host header to be overridden."
"set" should probably be "use", and Content-Length should be in there
too. In fact, I'd require UAs to set Content-Length; while
theoretically you can chunk a request body, there are some practical
interop problems with doing so.
Could you elaborate on that?
Not applicable any more -- see above.
[...]
What about automatically setting headers to do with delta encoding
(RFC3229)? TE (for transfer encoding negotiation)? Content-MD5 (for
request body integrity)? Meter (HTTP hit metering from caches)? The
UA-* request headers? MUST NOT is too strong a prohibition for
automatically-set headers; I'd suggest SHOULD NOT. (The response shown
in the "Manipulating response headers" example is actually impossible
for conforming implementations to see; you need to send TE to get a
Transfer-Encoding back).
Would it work if I removed "Transfer-Encoding: chunked" from the
example? And what are your suggestions for those other headers?
My suggestion would be to weaken "User agents MUST NOT set any headers
other than the headers set by the author using this method" to SHOULD
NOT.
Ok, made that change for now as it sounds reasonable to me.
Also, add TE to the list of headers that UAs MAY add.
It MUST NOT be overriden?
[...]
setRequestHeader() is the problem. Something like this would improve it;
"UAs MAY set the Authorization header, based upon the operation of HTTP
Authentication [RFC2617 ref]. If a challenge from the server is
encountered, credentials SHOULD be generated based upon the values of
the username and password specified by open(). UAs MUST NOT set the
Authorization header solely because open() contains a username/password;
it should only be set as part of the protocol described by HTTP
Authentication [RFC2617 ref]."
That probably needs some massaging to take account of the precedence
rules for sourcing username and password. It's tricky, because the UA
can optimistically send Authorization, based upon previous challenges
sent; you just don't want the UA sending it without having seen a
challenge.
Used that text for now and added a note about rewording.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
