Server, HTTP and site considerations

Posted on by : admin Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

HTTP 1.1 application

Where possible, HTTP 1.1 or versions that are more recent should be used at the server. This is compatible with earlier clients, and also improves the efficiency and robustness of the network environment.

Cache expiration date

Well-engineered Web sites shall incorporate a cache expiration date that reflects the rate of change of the data being provided. This date should not exceed the date of content expiration (see 7.3). Caching servers should not retain pages longer than the cache expiration date.

Non-caching

Well-engineered Web sites shall not disable caching unless the rate of content change relevant to the users is high, the data is unique to a specific user, or data security/sensitivity warrant such treatment. Collection of hit count statistics, or ‘pushing’ secondary content (e.g. advertising) should not be allowed to impact response times nor to increase network overhead.

Browser language selection

Well-engineered Web sites should evaluate the client’s human language environment selection and initialize or deliver pages responsive to this within the overall context of the target-user community. The user should be able to select the language of preference from the browser environment, and this should be provided to the server via the HTTP “Content-Language” header. If the preferred language is not available, then the user should be given a selection of languages, if these are available. When a user has elected to see a page in a specific language, this should override the user’s preset preference; and this may require use of information about the link that lead to the target page (see 7.5.5.) Automated translation tools may provide capabilities that meet the need for multilingual delivery. These may be more effective if Web contents are developed with automated translation as an objective. The Web design should consider the possible implications of user initiated automatic translation.

Robot exclusion

Servers shall incorporate robot exclusion elements (see Annex E) based upon the implications of indexing external to the site. The use of robot technology within a Web site to create indexes or searching WEPs shall respect these guidelines.

Browser tolerance

Web sites should monitor client browsers and capabilities as a basis for ongoing environmental documentation updates. Well-engineered Web site designers should also remain aware of the need for the Web site to be tolerant of browsers not currently in use by clients, especially because people who are disabled and people with different browsers may join the client group at any time.

HTML validation

Well-engineered Web pages should be submitted for either internal or external validation of HTML or XML for DTD conformance28 using tools such as those developed by the W3C (http://validator.w3.org) (see [B58]). Submission of well-engineered Web pages to validation tools shall be done in a way that is consistent with the proprietary nature of the information content.

Webmaster contact

E-mail to “Webmaster@domain” shall provide a point of contact for the site. The point of contact e-mail address shall exist and be actively monitored for messages in keeping with the criticality of the site(s). This may be necessary to notify a site of problems that preclude successful access to the site or its proper content. This is a required e-mail address, even if it is not part of the page content. This is not an alternative for having information concerning the content owner, the person responsible for the information content presented.

The person(s) actively monitoring for messages should direct the message to the person(s) assigned the responsibility for responding to the message. A Web site may have multiple Webmasters responsible for independent subsets of the Web site. In this case, the person(s) monitoring for messages should direct the message to the appropriate internal Webmaster.

Redirection

Redirection can be initiated by a server to provide better response to user request. Reasons for applying redirection include: a) Page location changes (see 4.2.8). b) Catch directory changes and direct request to the correct URI. c) To accept and resolve mistyped URIs. d) Eliminating case dependencies in URIs. e) Adjusting for differences in object name extensions (e.g., htm/html, jpg/jpeg, etc). f) Common spelling errors that may be site-specific. g) Provide default for attempts to access directories. h) Delivering selected well-engineered Web pages to client from a selection list. i) To accommodate language preference (see 6.3.7). j) To accommodate text-only preference.

Redirection has the advantage of providing back the corrected URI so that bookmarking occurs with this version. The design should consider the value of having directions for users to implement the redirection manually, when appropriate. Servers should respond to attempts to access invalid links within an existing site by redirecting such requests to a defined working page with an explanation of the error and some navigational hints. Redirection or refresh of a page shall not inhibit a user’s ability to navigate to prior pages.

Users shall be allowed to return to the page from which they initiated a hyperlink [this relates to requirement 22(o) of 36 CFR 1194, U. S. regulation on accessibility, commonly called Section 508. Portions of 36 CFR 1194 are provided in Annex I].