Movatterモバイル変換
[0]ホーム
This document is a set of good practices to improve implementationsofHTTP and related standardsas well as their use. It explains a few basic concepts, points out common mistakes and misbehaviors, and suggests "best practices".
This document doesnot incriminate any specific product. W3C does not track bugs or errors in implementations. That information is generally tracked by the vendors themselves, or third parties.
This document is the first public version of a Note,published on January 28th, 2003, and made available for discussion only by the editor and authors as part of their work asW3C Team participants in theQuality AssuranceActivity.Publication of this Note by W3C does not imply endorsement by W3C, including the W3C Team and Membership.
This document may be updated, replaced, or obsoleted by other documents at any time.
No formal commitment is made by W3C to invest additional resources in topics addressed by this Note. However, comments are welcomeand the W3CQuality Assurance Teammay publish an amended version should the amount and quality of the received comments prove it worthwhile or necessary.
Please send comments to thepublicly archivedmailing-list of theQuality Assurance Interest Group:www-qa@w3.org.
A list ofacknowledgederrors and proposed corrections can be found at http://www.w3.org/QA/2002/12/chips-errata.
Translation of this document is welcome. However, before starting a translation of this document, please be sure to read theinformation on translations, in ourCopyrightFAQ, and check thelist of existing translations of this document (available athttp://www.w3.org/QA/translations#chips)..
A list of currentW3C technicalreports and publications, including Working Drafts and Notes,can be found at http://www.w3.org/TR/.
HTTP andURIs are the basis of the World Wide Web, yet they are oftenmisunderstood, and their implementations and uses are sometimes incomplete or incorrect.
This document tries to improve this situation by providing a set of good practices to improve implementationsofHTTP and related standards(Web servers, server-side Web engines), as well as their use.
This document only deals with the server-side aspect ofHTTP,people looking forHTTP implementation problems in Web user agents should have a look at the user-agent counterpart of this document : "Common User-Agent Problems" [CUAP].
This document is a set of known problems and/or good practicesforHTTP implementations and their use, aimed at:
- developers implementing Web servers or proxies,
- developers implementing server-side scripting languages and engines, web content management or generation systems, etc. (referred to, across this document, as "Server-side engine developers"),
- and webmasters, Web site managers (referred to,across this document, as "Content Managers").
Unless specifically mentioned, what is referred throughout this document as "HTTP" is RFC2616,a.k.a.HTTP/1.1 [RFC2616].
Organization of this document : Guidelines, checkpoints
This document's organization is inspired fromWAI guidelines, especiallyUAAG.
This document is divided into 12 guidelines and associated checkpoints. Each guideline is a general good practice, whereas the associated checkpoints are practical applications of the guideline. Checkpoints are themselves divided inone or more provision(s).
A guideline can, and will in most cases, have several associated checkpoints.
Targets associated with the checkpoints
Checkpoints and their provisions are tagged according to theirprimary target.
- Checkpoints targeted at server (Web servers or proxies) implementors are tagged asSI,
- Checkpoints targeted at server-side engine (server-side scripting languages and engines, web content management or generation systems, etc.)developers are tagged asSS,
- Checkpoints targeted at content managers (webmasters, Web site managers)are tagged asCM.
If a checkpoint is applicable to several or all of these targets, it will have several tags.The target of a checkpoint is the sum of the target of its provisions.
An example of guideline and checkpoint
Here is an example of a guideline, with an associated checkpoint. Note the way they are presented, the multiple tags for the multiple targets of the checkpoint, etc.:
An example can be worth thousands of explanations.
sample provision for this checkpointCM
Here is a sample checkpoint text, within a sample guideline, with the actual markup used for guidelines and checkpoints.
another sample provision for this checkpointSSCM
In our example, the checkpoint has two provisions.
Example:
Checkpoints may include example, too.
This document is informative.
This document has no conformanceper se, but since it is about implementation and use of normative specifications (such asHTTP/1.1), one should consider following this set of guidelinesas a good step toward conformance to these specifications.
When possible, normative references will be mentioned for each checkpoint.
This document uses RFC 2119 [RFC2119] keywords (capitalized MUST, MAY, SHOULD etc.) when referring to behaviors clearly definedby a normative specification. When not capitalized, these words should be interpretedas regular language and not as RFC2119 keywords.
As specified in theabstract,Thisdocument does not incriminate any specific product. W3C does notgenerally track bugs or errors in implementations. However,we welcome implementors and advanced users of such technologies tocontribute to this document by providing techniques related to this note's applicable guidelines and checkpoints for a specific implementation.
Contributions are welcome in thepublicly archivedmailing-list of theQuality Assurance Interest Group:www-qa@w3.org. Thepublic archivesfor this list acts as a repository of contributions. Alist of acknowledged contributions is available at http://www.w3.org/QA/2002/12/chips-techniques.
We shall start by explaining in detailsURIs, and their underlying concepts.
URIs are defined in:
A common mistake, responsible for manyHTTP implementations problems, is to think this is equivalent to a filename within a computer system.This is wrong. URIs have, conceptually, nothing to do with a file system.One should remember that at all times when dealing with the World Wide Web.
To understand properly what aURI is, one has to think of the World Wide Web as a giant warehouse with an enormous amount of merchandise stored in boxes.
In this warehouse, aURI is not "row 12, 42nd box". AURIis not "that big black box over there", nor the content of the box. The URI is, exactly "The toothbrush can be found at row 12, 42nd box".
AURI is, actually, areference to a resource, with fixed and independent semantics.An interpretation of this definition is that theURI is some sort of serial number for one of the many merchandises in the warehouse. "Fixed semantics" means that we know that in a box referenced by this serial number, there will be a specific product (we'll use a toothbrush for our metaphor).Always. We know neither the color nor the shape of the toothbrush, but we are certain that whenever and however wedereference theURI(which means, whatever way one (whoever) chooses to learn which box is referenced by theURI, the resource willalways be a toothbrush.
Note that theURIis notexactly a serial number, since a serial numberdoes not have any specific semantic, and it can be a reference to multiple instances.
Also, if you upgrade from toothbrush to a newer version of the toothbrush ("toothbrush v2"), the serial number may change. However, its definition "our toothbrush" will not change.One may thus think of theURIas being the identification of a specific semantic, and theHTTPETag ([RFC2616] section 14.19) being the real serial number.
TheURIhttp://www.example.com/products/toothbrush is then a fixed reference to aspecific semantic, rather than being a serial number.
Note also that theHTTPEtag can be shared by identical resources thathave differentURIs.For example, ifhttp://mirror1.example.org/foo andhttp://mirror2.example.org/foo share thesame ETags, you can then deduct that those are equivalent resources.
The fixed semantics of aURIis one of the most important, yet often overlooked, concepts aboutURIs.
Tim Berners-Lee, creator of the World Wide Web, has written in 1998 an article named "CoolURIs don't change"[COOLURIs]stressing out this point and explaining how to useURIs properly.
Thanks to our warehouse metaphor, it is obvious thatURIs should not change: people looking for a resource will have a lot of trouble finding it if the actual references for the resource changes, hence making the original reference pointing to... nothing.
This is all the more important on the Web (more than in our warehouse example) because the Web is built upon hyperlinks, which themselves useURIs. WhenURIs are broken, following hyperlinks ( or "bookmarks", which are a form of hyperlinks ) does not lead to the expected resource. In other words, from a server point of view, this means that the resource would miss some traffic... Traffic being the final aim of any content provider(as selling toothbrushes is the final goal of the warehouse owner), behaviors resulting in a loss of traffic should therefore be avoided.
As Tim Berners-Lee points out,When you change aURI on your server, you can never completely tell who will have links to the oldURI. They might have made links from regular Web pages. They might have bookmarked your page. They might have scrawled theURI in the margin of a letter to a friend.
. In other words, as Jacob Nielsen's writes,Persistent URLs Attract Links, Link-rot equals lost business
.
We have seen why one should avoid breakingURIs. The following guidelines focus on techniques and strategies to avoid breakingURIs, or to fix them.
This section summarizes, paraphrases and extends the section called "So what should I do? DesigningURIs" inCoolURIs don't change[COOLURIs].
Use short URIs as much as possibleSSCM
In order to makeURIs easy to type, write down, spell, or remember, they should be short enough.
This checkpoint is not easy to quantify. However, we can take into account the fact that e-mail will be used to sendURIs, and e-mail clients (sender or receiver) are supposed to wrap at 70-80 characters : even though they are not supposed to wrap longURIs, some do. As a result 80 characters is a reasonable total length forURIs (includingURI scheme, e.g "http://", and host name).
Please note, however, that this length limit is by no mean a technical limitation, but rather, a practical goal to pursue.
Choose a case policyCM
URIs are partly case sensitive which means that, for examplehttp://www.example.com/foo andhttp://www.example.com/FOO are differentURIs and may refer to different resources.
Again, in order for theURIs to be easy to spell and remember, their case should not only be good (see following provisions of this checkpoint) but also consistent. It is thus recommended to choose a case policy, and enforce its use.
- AvoidURIs in Mixed caseSSCM
A case policy should be chosen, and enforced. All policies are, however, not equally preferable.Mixed-caseURIs should be avoided.
Example of a URI following a mixed-case policy:
http://example.com/QAfOo/baRRoX
As a case policy choose either "all lowercase" or "first letter uppercase".SSCM
We suggest that either "all lower-case" or "first-letter uppercase" policy be chosen.Among these two, "all lower-case" may be prefered for its simplicity.
Example, "all lower-case":
http://www.example.com/foo/bar-bar
Example, "first-letter uppercase":
http://www.example.com/Foo/Bar-bar
As we said in the beginning of this chapter, aURI is not a filename, and you do not need to tie yourURI structure to the file system on the Web server. However, chances are the resources served by a Web server will be available on a specific file system, and thus there should be flexible ways to map one onto the other.
2.2:Standard redirectsSICM Allow the use of standard redirectsSI
Content manager should be able to change easily the configuration of theserver to use the variousHTTP/1.1redirection schemes (section 10.3 of theHTTP/1.1specification [RFC2616]) :
The content manager should be allowed to use these, either by modifying directly the server configuration or by another indirect way of doing it (local configuration modification file, creation of local "redirect"resources, etc.)
Note that even though the current practice is to use the302 Foundstatus code for temporary redirects, it is best kept for "undefined" redirects, and the307 Temporary Redirect status code should be preferred for this purpose.
When you changeURIs, use standard redirectsCM
If for any reason a content manager change theURI referencing to a given resource, standard redirects, as defined above, should be used to avoid link-rot.
Usually, theHTTP 301 Moved Permanently status code([RFC2616], section 10.3.2) will be used for this purpose.
URIs should be both stable and independent. By independent we mean thataURI should always reference the same resource, regardless of the context (time, location, user, user-agent, etc.)
Serve dynamic content with technology-independentURIsSSCM
AURI should not show the underlying technology (server-side contentgeneration engine, script written in such or such language) used to serve the resource.
UsingURIs showing the specific underlying technology means one is dependent on the technology used, which means that the technology cannot be changed without either breakingURIsor going through the hassle of "fixing" them (see Checkpoint2.2: Standard redirects).
Using a scripting language to create dynamic content does not mean yourURI should end with the same extension as the script's filename.
Advertizing one's development environment to the world also imply security issues. One's site may have been crawled and be a known target for a specific architecture once a security flaw is discovered on that architecture. Obscurity is, of course, no replacement for security, but a good design keeps threats away.Read the Web Security FAQ [WSFAQ] for more on web server-side security.
For these reasons, technology-specific extensions shouldbe hidden, using content-negotiation (seeGuideline 7: Server-driven content negotiation.), proxying orURI mapping technologies.
Serve static content without file extensionCM
The reason why one should serve static content without file extensionis similar to the reason stated above : the content manager may, at some point, want to change the document format usedto serve a resource, yet the resource would remain "equivalent". For example, switching from an image file format to an equivalent format, or switching from plain text to HTML...
File extensions should therefore be hidden for static content, using content-negotiation (seeGuideline 7: Server-driven content negotiation.), proxying orURI mapping technologies.
3.2:Identification and Session mechanismsSSCM HTTP/1.1provides a number of mechanisms for identification, authentication and session management. Using these mechanisms instead of user-based or session-basedURIs guarantees than theURIs used to serve resources aretruly universal (allowing, for example, people to share, send, or copy them).
Use standard identification instead of per-userURIsSSCM
For the reasons stated above, standard identification mechanisms shouldbe prefered over user-dependentURIs.
Standard identification mechanisms for the World Wide Web are described inRFC 2617 : "HTTP Authentication: Basic and Digest Access Authentication" [RFC2617].
Use standard session mechanisms instead of session-basedURIs.SSCM
For the reasons stated above, standard session mechanisms shouldbe prefered over session-dependentURIs.
The latter may only be used in very specific cases, when standard mechanisms do not provide the desired features.
Example of an acceptable practice:
AURI may have some modifiers, like "?" used to pass arguments for cgi, or ";" to pass other kind of arguments or context information. Used for information tracking, this is a proper use of session information inURIs.
Example of a bad practice:
Bob tries to visithttp://www.example.com/resource,but since it's a rainy Monday morning, he gets redirected tohttp://www.example.com/rainymondaymorning/resource.The day after, when Bob tries to access the resource he had bookmarked earlier, the server answers that Bob has made a bad request, and serveshttp://www.example.com/error/thisisnotmondayanymore. Had the server servedbackhttp://www.example.com/resource because the Monday session had expired,it would have been, if not acceptable, at least harmless.
Standard session mechanisms includeRFC 2109 : "HTTP State Management Mechanism" [RFC2109],also known as "cookies".
One misconception aboutCoolURIs don't change
is that it advocates "frozen" documents, which content cannot change because that would "break things".
This, again, comes from a misunderstanding of the concept ofURIs. If we come back to our warehouse metaphor, used in the beginning ofthis document, things get clearer: we know that theURI is a fixed reference to a resource (a "toothbrush" in our example), and we know thatthe reference should not change, however it does not mean that the resourceitself should not change... On the contrary, the World Wide Web has been designed with evolution in mind, and if the resource is modified over time, this has nothing to do with the fact thatCoolURIs don't change
.
4.1:Standard redirects for changing contentSSCM Use standard redirects for changing contentSSCM
A good example of what is meant here by "changing/moving content"would be a daily article on a Web site. People want to be able to reference either the "latest daily article", or a specific article.
This is made possible and smooth with the use of two differentURIs (or,to be precise, oneURI referencing the "latest" issue, and one URI per article),as explained in the following example.
Let us consider an imaginary newsletter, issued every day. The (latest issue of the) newsletter is available athttp://www.example.org/newsletter and this is theURI people use to accessthe newsletter every day.
The content manager wants that every newsletter, and not only the latestissue, be available on his server, so he archives every issue, and each of themis accessible on the Web site at a datedURI, e.g:http://www.example.org/2042/02/12-newsletter for the Feb. 12, 2042 issue.
Using astandard redirect (HTTP 302 Found, or, even betterHTTP 307 Temporary Redirect - [RFC2616] section 10.3.3 and 10.3.8), the content manager, when publishing the Feb. 12, 2042 issue, redirectshttp://www.example.org/newsletter to the datedhttp://www.example.org/2042/02/12-newsletter
Readers are, therefore, able to refer to (and access) "the newsletter" for the latest issue, or to any specific issue.
If the server properly sends theContent-Location:HTTP/1.1 Header,there is an alternate technique, described inCheckpoint 5.2:Content-Location.
When removing a resource, use410 GoneCM
Most of guidelines 1 to 3 aim at avoiding "link rot", documents that have been moved or removed, resulting in a404 Not Foundstatus code for agents trying to access a resource once refered to by aURI.
This does not mean the web does not allow for documents to be removed or deprecated. Content managers should avoid, when possible, simply removing resources, and should consider instead the correct standard procedure,which is to use the410 gone status code ([RFC2616] section 10.4.11).
Whereas the404 Not found status code only means that the server is unable to find the resource, the410 gone status code means that the resource is intentionally unavailable. For the sake of semantics and caching (a410 gone is cacheable unless indicated otherwise).
Allow the content-manager to use410 Gone for removed resourcesSI
Content managers should be allowed to use the410 gone status code ([RFC2616] section 10.4.11) to remove or deprecateresources on a server. There should be an easy way to specify that a resource, or an area, has been removed, using the410 gone status code.
This section deals with providing meaningful and clear information to indexing and crawling user-agents (also often referred to as "robots", "spiders", "crawlers"). It has a strong influence on the traffic fora Web site (both the traffic created by the indexing agents, and the trafficattracted by search results) and should be a primary concern for contentmanagers.
Discussing the use of metadata, and the proper structuring of HTML documentsin order to help indexing agents in their task is out of scope for this document, we will, rather, focus on the inner mechanics of indexing.Readers interested in metadata may find interesting bits in these two relatedguidelines:Guideline 8: Provide useful metadata in addition to content negotiation andGuideline 12: Enrich and enhance.
Define site-wide indexing policyCM
A site-wide policy specifies what the default behavior ofindexing or crawling agents should be, and can be refined on a per-documentbasis through local indexing directives. (see below for details)
Content managers should define such a policy for their site.The most common way of informing indexing agents of this policy is theRobots Exclusion Protocol [ROBOTSPROTO], but one could use other technologies, such as a metadata database giving indexing directives on a document basis.
Define local indexing policyCM
The site-wide indexing policy may be completed by a local (per document) indexing policy, marked up at the document level.
For example, HTML [HTML 4.01]defines a specificMETAelementfor this purpose ([HTML 4.01] Section B.4.1).
This guideline relates to theCaching mechanismsdefined by theHTTP/1.1 specification ([RFC2616] section 13).
We will try to point out facts often overlooked or misunderstood aboutHTTP caching, as wellas giving advice on how to serve easily cachable content.
Send proper and accurateDate headerSI
HTTP/1.1 servers MUST send aDate: header ([RFC2616] section 14.18). It is the base of all caching mechanisms and must be sent both properly and accurately.
SendLast-Modified whenever possibleSISS
HTTP/1.1([RFC2616]) states thatservers SHOULD send theLast-Modified header ([RFC2616] section 14.29) whenever feasible
.This header is very important because of its use as a cache validator:a cache entry is considered to be valid if the entity has not been modified since the Last-Modified value
.
SendCache-Control directivesSI
TheCache-Control header ([RFC2616] section 14.9)defines the behavior of cache engines with regards to the resource sent.
Cache-Control should be preferred overExpires: ([RFC2616] section 14.21)because of its richness. Servers may send both, but be aware that agents aresupposed to ignoreExpires: if the max-age directive ofCache-Control: is properly sent.
6.3:Caching generated contentSS Provide actual caching information for content generated dynamicallySS
Most dynamic content generation systems act as if the documents they generate and serve were "fresh" (i.e as if the resource was last modified at the date it is served), whether the information itself is, or not.
This is a harmful lie for caching engines and should be avoided.
Regardless of the technology used, it should be possible to provide age information by retrieving the actual information from whatever source is used to generate the dynamic content:file,database, etc.
This guideline deals withnegotiation inHTTP/1.1 (as defined inHTTP/1.1[RFC2616] section 12).
Content negotiation stands for the server-driven negotiation based on user agent capabilities and user preferences, including those specified in theAccept ([RFC2616] section 14.1)Accept-Charset ([RFC2616] section 14.2), andAccept-Language ([RFC2616] section 14.4) headers, and beyond.
7.1:Format negotiationSICM "Format negotiation" here stands for the server-driven negotiation between equivalent instances of a resource in different "formats", either media-type (oftencalled "content-negotiation" erroneously) or character encoding.
Allow the content manager to use and configure content-type negotiationSI
Content-managers should be provided with an easy way to specify that several documents are different instances of the same resource using various "equivalent"media types.
Server should then apply server-driven negotiation algorithms to serve the most appropriate variant based at least on the requestedAccept ([RFC2616] section 14.1) header.
Allow the content manager to use and configure character encoding negotiationSI
Content-managers should be provided with an easy way to specify that several documents are different instances of the same resource with different character encoding.
Server should then apply server-driven negotiation algorithms to serve the most appropriate variant based at least on the requestedAccept-Charset ([RFC2616] section 14.2) header.
During format negotiation, be cautious with agents accepting anythingSICM
As explained for example in "Common user agent problems" ([CUAP] section "protocols"), some agents are known to misbehave with regard to format negociation, sending an HTTP header ofAccept: */* (thus they are supposed to support every and any content type, which they certainly do not).
While servers are not required to cope with this problem in user agents, a wisepractice toward agents sending brokenAccept: headers or not expressingspecific preference on the content type is to send them a version of the resource in a widelysupported document format.
This can be done at the server level using the quality factors used in thenegotiation process([RFC2616] section 12).
See also the related guideline :Guideline 11 : Use flexible technology instead of client sniffing/blocking.
Allow the content manager to set the quality factors used during negociationSI
Content-managers should be provided with an easy way to specify which version (either format or language) of the resource they would rather see served, in case the headers sent by the agent do not leave one clear choice.
See related checkpoint 9.1:When negotiation fails.
If server-driven negotiation fails, servers should either proceed to agent-driven negotiation or try fall-back solutions, as explained inGuideline 9 : Provide default and fall-back solutions.
Server-driven negotiation is used to serve the best content available, based on the accept headers received. This mechanism does not, however, specify variants beyond the genericVary:HTTP header.
This guideline gives hits at going a little further for the sake of ease of navigation through, and indexing of, multiple HTML documents (variants or collection).
8.1:Variants of (X)HTML documentsSSCM Specify variants of HTML documentsSSCM
TheHTML specification [HTML 4.01], providesmechanismsto specify (language) variants for a given document ([HTML 4.01] appendix B.4) using thelink element ([HTML 4.01] section 12.3).
When used with thealternate type, thelinkelement can specify variants of a given resource, either language variants (translations) with thelang attribute or media variants with themedia attribute.
Example of HTML markup for language variants:
<LINK rel="alternate" type="text/html" href="mydoc-fr.html" hreflang="fr" lang="fr" title="La vie souterraine"><LINK rel="alternate" type="text/html" href="mydoc-de.html" hreflang="de" lang="de" title="Das Leben im Untergrund">
Specify variants ofXHTML documentsSSCM
Note that this technique is is also applicable forXHTML documents.
Example of XHTML 1.0 markup for language variants (same as above, but with lower-case, closed elements...):
<link rel="alternate" type="text/html" href="mydoc-fr.html" hreflang="fr" lang="fr" title="La vie souterraine" /><link rel="alternate" type="text/html" href="mydoc-de.html" hreflang="de" lang="de" title="Das Leben im Untergrund" />
8.2:Navigation among (X)HTML documentsCM Facilitate navigation among collections of HTML documentsCM
Again, using thelink element ([HTML 4.01] section 12.3)one can specify relations betweens documents in a collection.
The link types which can be used for this purpose, as described in theData types section of the HTML 4.01 specification [HTML 4.01]are:
- Start
- Next
- Prev
- Contents
- Index
- etc.
examples of use:
- in a photo gallery (using
Next,Prev,Index, etc.) - for a periodical newsletter (using
Next,Prev,Copyright, etc) - in a compound document (using
Contents,Chapter,Section,Subsection,Appendix,Glossary, etc.)
HTTP [RFC2616] is about serving content in the most appropriate way, and, as we have seen in previous guidelines (Guideline 7 : Server-driven content negotiation andGuideline 8: Provide useful metadata in addition to content negotiation), server-driven negotiation may be used to servethe best available content. It may happen that these mechanisms fail, and in thiscase,HTTP implementationsshould try, when possible, to give the requested content to the client. This may be achieved through default and fall-back mechanisms.
9.1:When negotiation failsSISS provide multiple or default choice(s) when content/language negotiation fails to give only one resultSISS
Using the verbiage of theHTTPspecification, this checkpoint can be paraphrased into "use agent-driven negotiation when the server is unable to provide a varying response using server-driven negotiation".
Section 12 ofHTTP [RFC2616] provides mechanisms to leave the final decision to the user-agent (or its user) for cases when the content or language negotiation does not come up with a unique resultbut with multiple ones.
In such a case, a server can use the300 (Multiple Choices) status code, or be configured to send, by default, one of the resources among the possible choices.
provide default or fall-back choice(s) when content/language negotiation failsSISS
Section 12 ofHTTP/1.1[RFC2616] suggests the use of the406 (Not Acceptable)status code when content or language negotiation fails to find any appropriate negotiated resource.
However theHTTP/1.1 specification[RFC2616] also states thatthe server should make the best efforts to give the requested content to the client
.
One possible interpretation of this is that the server may provide fall-back choice(s):the message body for "HTTP 406 not acceptable" can give a list of available resources and let the user choose, or the server can be configured to serve, arbitrarily, a specific variant of the resource in case negotiation fails.
Note that this is perfectly acceptable with regards toSection 10.4.7 ofHTTP/1.1[RFC2616]: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable.
allow the content manager to set up a fall-back behavior content/language for cases when negotiation failsSISS
This is the practical implementation of the provision above.The server should allow the content manager to decide whether, in case negotiation fails, the server should:
- send a 406 (Not Acceptable) status code with a list of available choices,
- or if it should arbitrarily serve a variant of the resource. (The content manager should, of course, be allowed to choose which variant would be chosen,or how it should be chosen.).
Example:
Through theAccept-Language headers, a client specifies that it prefers Japanese or Englishversions of the resource, whereas the content is only available in French and Spanish. The content manager may be allowed to choose that the French version will be served as a default version, or let the server send a 406 status code, giving the user-agent a choice between the French and Spanish versions.
As a general rule, the content manager should be allowed to change and customize the body ofHTTP error messages.
Guideline 10: Serve resources with correct content-type and character encoding information
Send proper character encoding informationSISSCM
For some document types, the media type sent by theContent-typeHeader ([RFC2616] section 14.17) may be sent with some informationabout the character encoding of the document. In some cases, this is mandatory (see the provision belowfor HTML and XHTML).
Send proper character encoding information for XHTML documentsSISSCM
TheHTML 4.01 Recommendation ([HTML 4.01] section 5.2.2) states thatthe server should provide this information (the character encoding of the HTML document served), e.g:
Content-Type: text/html; charset=EUC-JP
Conforming user agents MUST observe the following priorities when determining an HTML document's character encoding (from highest priority to lowest):
- An HTTP "charset" parameter in a "Content-Type" field
- A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset"
- The charset attribute set on an element that designates an external resource.
Note that The HTTP/1.1 protocol ([RFC2616], section 3.7.1) mentions ISO-8859-1 as a default character encoding when the "charset" parameter is absent from the "Content-Type" header field, but it is now not recommended to follow thispractice.
The recommended practice is that the character encoding bebothspecified be specified in the META declaration,and the "Content-Type" header field.
Example of an HTML 4.01 document written in French with a UTF-8 encoding:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html lang="fr"><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"><title>Exemple de document HTML 4.01</title></head><body><h1>Portrait Intérieur</h1><h2>Rainer-Maria Rilke</h2><p>Ce ne sont pas des souvenirs<br>qui, en moi, t'entretiennent ;<br>tu n'es pas non plus mienne<br>par la force d'un beau désir.</p></body></html>
Send proper character encoding information for XHTML 1.0 documentsSISSCM
The case of XHTML document is similar to the case of HTML,except that, since XHTML is also XML,XHTML document can provide thecharacter encoding via the XML declaration. (but if the XHTML document uses one of the default encodings - UTF-8 or UTF-16 - no declaration is needed).
The recommended practice for XHTML documents is to properly specify the character encoding in both the XML declaration and the the "Content-Type" header field.
Example of an XHTML 1.0 document written in French with an ISO-8859-1 encoding:
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr"><head><title>Exemple de document XHTML 1.0</title></head><body><h1>Portrait Intérieur</h1><h2>Rainer-Maria Rilke</h2><p>Ce ne sont pas des souvenirs<br />qui, en moi, t'entretiennent ;<br />tu n'es pas non plus mienne<br />par la force d'un beau désir.</p></body></html>
Allow the content manager to override character encoding settingsSISS
The content manager should be allowed to set the character encoding information.
If the server implementor does not want the content manager, or if the content manager does not want the users to change the charset information sentby the HTTP server, then the server should send none, and the character encoding may be specified at the document level.
11.1:Avoid agent sniffingSSCM Use content-negotiated resources instead of Agent sniffingSSCM
Server-driven negotiation, based on the agent's capabilities (given though theAccept:header -[RFC2616 section 14.1 -) is a very efficient way of providing agents with content they can display or process, without doubt on their capabilities. It is also a cost-efficient technique, as the negotiation is handled by the server based on whatagents declare they can handle, whereas agent sniffing implies knowledge of (potentially all)agents and their capabilities in order to serve (only) content the agents can handle.
Providing (with negotiation) equivalent versions of a resource in flexible technologies should therefore be preferred to agent-sniffing.
Use flexible document technologies instead of Agent sniffingSSCM
Content manager often think they have to serve different content depending on the agent, either by generating different content on the fly using server-side technologies, filtering,negotiating, orBlocking.
However well done (negotiating being the most appropriate way), this practice is very seldom suitable to any possible agent, and implies a lot of extra work.
Content-managers should therefore consider the use of standard (i.e widely implemented), flexible (scalable, multi-platform, device independent, etc.) documenttechnologies whenever possible, either as a primary choice, or, at least, as a negotiatedalternative.
Example of an acceptable practice:
The content manager decides to serve a text resource using proprietary, not widely implemented technology, but adds a negotiated plain-text alternative for agents which can not handlethe proprietary document format.
11.2:Avoid agent blockingSSCM Avoid agent blockingSSCM
Even though some agents may be badly broken, refusing to serve content to users of such an agent means lost business (traffic), andflexible technologies, which ensure that the content may be handled by any agent, should be preferred to this practice.
Even worse is to choose which agents are "suitable" and block all the other agents.This is a very bad move, at least because:
- Some of the agents one may block are actually idexing agents for search engines, and may bring back traffic
- Agents are rapidly evolving, and while a specific version of a specific agent mayappear better at some point in time, there is no reason to believe another version of another agent may not be more appropriate later, hence making the blocking rules obsolete
- Blocking agents means refusing to serve, and ultimately means lost business (traffic).
Agent blocking should therefore be avoided as much as possible, and insteadflexible negotiation and document technologies, as described inCheckpoint 11.1,should be used.
The previous guidelines showed good practices for the implementation and use of Web servertechnologies. We will close this document by adding a few leads to practices which, even thoughthey are not crucial, may be followed to enrich or enhanceHTTP services...
- Use transfer encoding for bandwidth-constrained devicesSI
Serving content to bandwitdh-constrained devices (this includesamong many others, mobile devices), can be improved via on the fly connection, using theTransfer-EncodingHTTP header ([RFC2616] section 14.41).
You may use this table as a quick and convenient tool to assess your progress in following the guidelines given in this document.
The editor would like to thank the following W3C Team members for the initial input and their collaboration in writing this document.
The editor would also like to thank the following people for their early review of the document:
- RFC1630
- "UniversalResource Identifiers in WWW", T. Berners-Lee, June 1994.Available at http://www.ietf.org/rfc/rfc1630.txt.
- RFC2396
- "UniformResource Identifiers (URI): Generic Syntax",T. Berners-Lee et al., August 1998. Available athttp://www.ietf.org/rfc/rfc2396.txt.
- RFC2616
- "HypertextTransfer Protocol -- HTTP/1.1", R. Fielding et al., June 1999.Available at http://www.ietf.org/rfc/rfc2616.txt.
- RFC2617
- "HTTPAuthentication: Basic and Digest Access Authentication",J. Franks et al., June 1999. Available athttp://www.ietf.org/rfc/rfc2617.txt.
- RFC2119
- "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt
- RFC2109
- "HTTP State Management Mechanism", D. Kristol, L. Montulli, February 1997. Available at http://www.ietf.org/rfc/rfc2109.txt.
- HTML 4.01
- "HTML4.01 Specification", Dave Raggett, Arnaud Le Hors, Ian Jacobs,24 December 1999. Available athttp://www.w3.org/TR/1999/REC-html401-19991224/.
- COOLURIs
- "Cool URIs don't change",Tim Berners-Lee, 1998. Available at http://www.w3.org/Provider/Style/URI.html.
- CUAP
- "Common User Agent Problems",Karl Dubost, 28 January 2003. Available at http://www.w3.org/TR/2003/NOTE-cuap-20030128. Latest version at http://www.w3.org/TR/cuap.
- WSFAQ
- "TheWorld Wide Web SecurityFAQ", LincolnD. Stein & John N. Stewart. Available athttp://www.w3.org/Security/Faq/www-security-faq.
- ROBOTSPROTO
- "A Standard for Robot Exclusion", Martijn Koster et. al., 30 June 1994. Available at http://www.robotstxt.org/wc/norobots.html.
[8]ページ先頭