11.2.08

Skeleton .htaccess file for Powweb Hosting Customers

.htaccess file designed for powweb customers

read more | digg story

8.2.08

Update: AskApache Password Protect Plugin

Update for AskApache Password Protect Plugin that automates installation of .htaccess Server-based HTTP Basic Authentication including creating encrypted passwords for .htpasswd

read more | digg story

5.2.08

XMLHttpRequest and Basic Authentication

If the readyState attribute has a value other than 1 (Open), an INVALID_STATE_ERR exception must be raised. Otherwise, a request to url using method method is sent. url, if relative, must be resolved using window.document.baseURI of the window whose constructor is used. 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 for the entity body following these rules (the term entity body is defined by section 7.2.1 of [RFC2616]):

  • If data is a DOMString, it must be encoded as UTF-8 for transmission.
  • If the data is a Document, it must be serialized using the encoding given by data.xmlEncoding, if specified and supported, or UTF-8 otherwise [DOM3Core].
  • If data is not a DOMString or a Document the host language its stringification mechanisms must be used on the argument that was passed and the result must be treated as if data is a DOMString.

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

Authors should specify the Content-Type header via setRequestHeader before invoking send() with an argument. If the argument to send() is a Document and no Content-Type header has been set user agents must set it to application/xml for XML documents and to the most appropriate media type for other documents (using intrinsic knowledge about the document).

If the response is an HTTP redirect (status code 301, 302, 303 or 307), then it must be transparently followed (unless it violates security, infinite loop precautions or the scheme isn't supported). Note that HTTP ([RFC2616]) places requirements on user agents regarding the preservation of the request method during redirects, and also requires users to be notified of certain kinds of automatic redirections.

Once the request has been successfully acknowledged readyState must be set to 2 (Sent). 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) immediately after having gone to 3 (Receiving).

If something goes wrong (infinite loop, network errors) the readyState attribute must be set to 4 (Loaded) and all other members of the object must be set to their initial value.

In future versions of this specification user agents will be required to dispatch an error event if the above occurs.

If the user agent 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 user agent supports HTTP Authentication ([RFC2617]) it should consider requests originating from this object 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, user agents should prompt the users for credentials.

If the user agent 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 user agent 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 user agent generated conditional request must be presented as 200 OK responses with the appropriate content. Such user agents 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 user agent 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.

If the user agent supports Expect/Continue for request bodies ([RFC2616]) it should insert Expect headers and handle 100 Continue responses appropriately.

abort(), method

When invoked, this method must cancel any network activity for which the object is responsible and set all the members of the object to their initial values.

getAllResponseHeaders(), method

If the readyState attribute has a value other than 3 (Receiving) or 4 (Loaded), user agents must raise an INVALID_STATE_ERR exception. Otherwise, it must return all the HTTP headers, as a single string, with each header line separated by a CR (U+000D) LF (U+000A) pair. The status line must not be included.

// 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
getResponseHeader(header), method

If the header argument doesn't match the field-name production a SYNTAX_ERR must be raised. Otherwise this method works as described below.

If the readyState attribute has a value other than 3 (Receiving) or 4 (Loaded), the user agent must raise an INVALID_STATE_ERR exception. Otherwise, it must represent the value of the given HTTP header (header) in the data received so far for the last request sent, as a single string. If more than one header of the given name was received, then the values must be concatenated, separated from each other by an U+002C COMMA followed by an U+0020 SPACE. If no headers of that name were received, then it must return null. Header names must be compared case-insensitively to the method its argument (header).

// The following script:
var client = new XMLHttpRequest();
client.open("GET", "test.txt", true);
client.send();
client.onreadystatechange = function() {
if(this.readyState == 3) {
print(client.getResponseHeader("Content-Type"));
}
}

// ...should output something similar to the following text:
Content-Type: text/plain; charset=utf-8
responseText of type DOMString, readonly

If the readyState attribute has a value other than 3 (Receiving) or 4 (Loaded), the user agent must raise an INVALID_STATE_ERR exception. Otherwise, it must be the fragment of the entity body received so far (when readyState is 3 (Receiving)) or the complete entity body (when readyState is 4 (Loaded)), interpreted as a stream of characters.

If the response includes a Content-Type understood by the user agent the characters are encoded following the relevant media type specification, with the exception that the rule in the final paragraph of section 3.7.1 of [RFC2616], and the rules in section 4.1.2 of [RFC2046] must be treated as if they specified the default character encoding as being UTF-8. Invalid bytes must be converted to U+FFFD REPLACEMENT CHARACTER. If the user agent can't derive a character stream in accord with the media type specification, reponseText must be null.