Rephrased the note about the clock skew vulnerability of the Expires header.

Author: lanthaler

book/http_cache.rst

@@ -464,11 +464,12 @@ The resulting HTTP header will look like this::
     The ``setExpires()`` method automatically converts the date to the GMT
     timezone as required by the specification.
 
-Note that the ``Expires`` header is not vulnerable to clock skew, since the
-lifetime is calculated using the ``Date`` header which comes from the
-origin server as well instead of using the local clock.
-The specification states that "HTTP/1.1 servers should not send ``Expires`` dates
-more than one year in the future."
+Note that in HTTP versions before 1.1 the origin server wasn't required to
+send the ``Date`` header. Consequently the cache (e.g. the browser) might
+need to rely onto his local clock to evaluate the ``Expires`` header making
+the lifetime calculation vulnerable to clock skew. Another limitation
+of the ``Expires`` header is that the specification states that "HTTP/1.1
+servers should not send ``Expires`` dates more than one year in the future."
 
 .. index::
    single: Cache; Cache-Control header
@@ -1045,4 +1046,4 @@ Learn more from the Cookbook
 .. _`HTTP Bis`: http://tools.ietf.org/wg/httpbis/
 .. _`P4 - Conditional Requests`: http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-12
 .. _`P6 - Caching: Browser and intermediary caches`: http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-12
-.. _`ESI`: http://www.w3.org/TR/esi-lang
+.. _`ESI`: http://www.w3.org/TR/esi-lang