From W3C Wiki
Revision as of 12:12, 11 August 2012 by Zruset (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Common HTTP Implementation Problems

CHIPs is a set of good practices to improve implementations of HTTP and related standards as well as their use. It explains a few basic concepts, points out common mistakes and misbehaviors, and suggests "best practices".


We plan to republish this document under the umbrella of W3C QA IG. The decision has been taken at the W3C Technical Plenary on March 2006 at Cannes Mandelieu: CUAP and CHIPs


  • Mapping from CHIPs to Web Architecture document
  • Template for reformatting the "guidelines"
  • Include Errata from previous publication (see work done in 2003)
  • Figure out from Web Architecture what's missing
  • Hunting for new issues

Mapping from CHIPs to Web Architecture

Understanding URIs

global mapping to section 2 of webarch - identification 
  • Guideline 1: Choose URI s wisely
    • Short URIs
      • Use short URIs as much as possible
  • URI case policy
    • Choose a case policy
    • Avoid URIs in Mixed case
    • As a case policy choose either "all lowercase" or "first letter uppercase".
  • Guideline 2: Allow URI management
    • URI mapping
      • Provide mechanisms for File System to
  • Standard redirects
    • Allow the use of standard redirects
    • When you change <acronym title="Uniform Resource Identifier">URI</acronym>s,
  • Guideline 3: Use independent URIs
    • Technology-independent URIs
      • Serve dynamic content with technology-independent
      • Serve static content without file extension
  • Identification and Session mechanisms
webarch 3.5.2. Linking and access control
3.5.3. Supporting Navigation 
  • Use standard identification instead of per-user
  • Use standard session mechanisms instead of session-based URIs
  • Guideline 4: "Cool URIs don't change", but cool content does
3.5.1. URI persistence webarch
  • Standard redirects for changing content
    • Use standard redirects for changing content
  • 410 Gone
    • When removing a resource, use 410 Gone
    • Allow the content-manager to use 410 Gone
  • Guideline 5: Provide indexing agents with useful information
  • Indexing policy
    • Define site-wide indexing policy
    • Define local indexing policy
  • Content-Location
    • Send valid Content-Location:
    • Use Content-Location: for changing content
    • Allow the content-manager to set the Content-Location: header
  • Content-Md5
    • Send Content-Md5 for integrity check
  • Guideline 6: Provide appropriate caching information
  • Cache-related HTTP headers
    • Send proper and accurate
    • Send Last-Modified whenever possible
    • Send Cache-Control directives
  • Cache policy
    • Define a cache policy
    • Allow the Content Manager to set up cache control
  • Caching generated content
    • Provide actual caching information for content
    • Send the same answer to HTTP HEAD and HTTP GET requests SI

Serving Content Appropriately

  • Guideline 7: Server-driven content negotiation
3.2.2. Fragment identifiers and content negotiation
3.5.1. URI persistence (content negotiation) 
  • Format negotiation
    • Allow the content manager to use and configure content-type negotiation
    • Allow the content manager to use and configure
    • During format negotiation, be cautious with agents accepting anything
    • Allow the content manager to set the quality factors used during negociation
  • Language negotiation
    • Allow the content manager to use and configure language negotiation
    • Allow the content manager to set the quality factors used during negociation
    • Use the Content-Language: HTTP header
  • Guideline 8: Provide useful metadata in addition to content negotiation
  • Variants of (X)HTML documents
    • Specify variants of HTML documents
    • Specify variants of <acronym title="eXtensible Hypertext Markup Language">XHTML</acronym> documents
  • Navigation among (X)HTML documents
    • Facilitate navigation among collections of HTML documents
  • Guideline 9: Provide default and fall-back solutions
Conflicts (?) with webarch 5.3. Error Handling  esp:
Principle: Error recovery

Agents that recover from error by making a choice without the user's consent are not acting on the user's behalf.

  • When negotiation fails
    • provide multiple or default choice(s) when content/language negotiation fails to give only one result
    • provide default or fall-back choice(s) when content/language negotiation fails
    • allow the content manager to set up a fall-back behavior content/language for cases when negotiation fails
  • HTTP error messages body
  • Guideline 10: Serve resources with correct content-type and character encoding information
  • Content-type
    • Send proper Content-type HTTP header
    • allow the content manager to override content-type settings
  • Character Encoding
    • Send proper character encoding information
    • Send proper character encoding information for XHTML documents (!! should be HTML)
    • Send proper character encoding information for XHTML 1.0 documents
    • Allow the content manager to override character encoding settings
  • Guideline 11: Use flexible technology instead of client sniffing/blocking
  • Avoid agent sniffing
    • Use content-negotiated resources instead of Agent sniffing
    • Use flexible document technologies instead of Agent sniffing
    • Avoid agent blocking
  • Avoid agent blocking
  • Guideline 12: Enrich and enhance
  • Transfer encoding
    • Use transfer encoding for bandwidth-constrained devices
  • From (meta)data to server information
    • Convert (meta)data into

Things in WebArch that should/could be matched in CHIPs

Other possible additions

More examples - apache, iis, jigsaw, php, rails, whatever...

ERRATA - things to fix

fix part about best effort to provide representation -> server may decide, but user agent should detect accept mismatch and warn user

Issues to add

  • AJAX vs "everything has an URI"
  • get vs post vs xmlhttprequest