Re: Headers / caches proposal (2nd revision)

Based on Revision 1.20:

* Change to send method; replace all text to the Parameters header with:

---8<---
If the readyState attribute has a value other than 1 (Open), an  
exception must be raised. Otherwise, the readyState attribute must be  
set to 2 (Sent) and a request to uri using method method is sent. If  
the async flag is set to false, then the method must not return until  
the request has completed. Otherwise, it must return immediately  
(See: open()).

If data is passed to the send() method, it must be used to create the  
entity body, using the following rules;

1) If data is a DOMString, the entity body must be encoded as UTF-8.

2) If data is a Document, then the entity body must be serialised  
using the encoding given by data.xmlEncoding, if specified, or UTF-8  
otherwise [DOM3].

3) If data is not a DOMString or Document, the host language must use  
the stringification mechanisms on the argument that was passed.

Invoking send() without the data argument must give the same result  
as if it was invoked with null as argument.

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

If the UA allows the specification of a proxy, it should modify the  
request appropriately; i.e., connect to the proxy host instead of the  
origin server, modify the Request-Line and send Proxy-Authorization  
headers as specified.

If the UA supports HTTP Authentication [RFC2617],  it should consider  
XHR calls to be part of the protection space that includes the  
accessed URIs, and send Authorization headers and handle 401  
Unauthorised requests appropriately. if authentication fails, UAs  
should prompt the users for credentials.

If the UA supports HTTP State Mangement [RFC2109 RFC2965], it should  
persist, discard and send cookies (as received in the Set-Cookie and  
Set-Cookie2 response headers, and sent in the Cookie header) as  
applicable.

If the UA implements a HTTP cache [RFC2616], it should respect Cache- 
Control request headers set by the author (e.g., "Cache-Control: no- 
cache" bypasses the cache). It must not send Cache-Control or Pragma  
request headers automatically unless the user explicitly requests  
such behaviour (e.g., by force-reloading the page). 304 Not Modified  
responses that are a result of a UA-generated conditional request  
must be presented as 200 OK responses with the appropriate content.  
Such UAs must allow authors to override automatic cache validation by  
setting request headers (e.g., If-None-Match, If-Modified-Since), in  
which case 304 Not Modified responses must be passed through.

If the UA implements server-driven content-negotiation [RFC2616], it  
should set Accept-Language, Accept-Encoding and Accept-Charset  
headers as appropriate; it must not automatically set the Accept  
header. Responses to such requests must have content-codings  
automatically removed.
Immediately before receiving the message body (if any), the  
readyState attribute must be set to to 3 (Receiving). When the  
request has completed loading, the readyState attribute must be set  
to 4 (Loaded). In case of a HEAD request readyState must be set to 4  
(Loaded) immediatly after having gone to 3 (Receiving).

If the UA supports Expect/Continue for request bodies [RFC2616], it  
should insert Expect headers and handle 100 Continue responses  
appropriately.

--->8---

* Change to setRequestHeader method; replace all text to the  
Parameters header with:

---8<---
The nominated request header field value must be set to value, with  
the following exceptions;

1) If the readyState attribute has a value other than 1 (Open), an  
exception must be raised.

2) Nothing must be done if the header or value arguments contain any U 
+000A LINE FEED or U+000D CARRIAGE RETURN characters, or if the  
header argument contains any U+0020 SPACE or U+003A COLON charecters.

3) UAs must not allow the following headers to be set by authors:
   Accept-Charset, Accept-Encoding, Content-Length, Expect, Date,  
Host, Keep-Alive, Referer, TE, Trailer, Transfer-Encoding, Upgrade

[example]

Implementations must replace any existing value if the nominated  
request header field value is one of:
   Authorization, Content-Base, Content-Location, Content-MD5,  
Content-Range, Content-Type, Content-Version, Delta-Base, Depth,  
Destinaion, ETag, Expect, From, If-Modified-Since, If-Range, If- 
Unmodified-Since, Max-Forwards, MIME-Version, Overwrite, Proxy- 
Authorization, SOAPAction, Timeout

Otherwise, if the nominated request header field already has a value,  
the new value must be combined with the existing value, as specified  
by [RFC2616 Section 4.2].
See also the send() method regarding UA header handling for caching,  
authentication, proxies, and cookies.

The list of request headers must be reset when the open() method is  
called.

--->8---

--
Mark Nottingham
mnot@yahoo-inc.com

Received on Wednesday, 3 May 2006 01:12:05 UTC