<pre>Network Working Group                                          I. Cooper
Request for Comments: 3143                                 Equinix, Inc.
Category: Informational                                        J. Dilley
                                               Akamai Technologies, Inc.
                                                               June 2001


                   <span class="h1">Known HTTP Proxy/Caching Problems</span>

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document catalogs a number of known problems with World Wide Web
   (WWW) (caching) proxies and cache servers.  The goal of the document
   is to provide a discussion of the problems and proposed workarounds,
   and ultimately to improve conditions by illustrating problems.  The
   construction of this document is a joint effort of the Web caching
   community.

Table of Contents

   <a href="#section-1">1</a>.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-2">2</a>
   <a href="#section-1.1">1.1</a>   Problem Template . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-2">2</a>
   <a href="#section-2">2</a>.    Known Problems . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
   <a href="#section-2.1">2.1</a>   Known Specification Problems . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
   <a href="#section-2.1.1">2.1.1</a> Vary header is underspecified and/or misleading  . . . . . .  <a href="#page-5">5</a>
   <a href="#section-2.1.2">2.1.2</a> Client Chaining Loses Valuable Length Meta-Data  . . . . . .  <a href="#page-9">9</a>
   <a href="#section-2.2">2.2</a>   Known Architectural Problems . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
   <a href="#section-2.2.1">2.2.1</a> Interception proxies break client cache directives . . . . . <a href="#page-10">10</a>
   2.2.2 Interception proxies prevent introduction of new HTTP
            methods  . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-11">11</a>
   2.2.3 Interception proxies break IP address-based authentication . 12
   <a href="#section-2.2.4">2.2.4</a> Caching proxy peer selection in heterogeneous networks . . . <a href="#page-13">13</a>
   <a href="#section-2.2.5">2.2.5</a> ICP Performance  . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
   2.2.6 Caching proxy meshes can break HTTP serialization of content 16
   <a href="#section-2.3">2.3</a>   Known Implementation Problems  . . . . . . . . . . . . . . . <a href="#page-17">17</a>
   <a href="#section-2.3.1">2.3.1</a> User agent/proxy failover  . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
   2.3.2 Some servers send bad Content-Length headers for files that
            contain CR . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-18">18</a>



<span class="grey">Cooper &amp; Dilley              Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


   <a href="#section-3">3</a>.    Security Considerations  . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
         References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
   <a href="#appendix-A">A</a>.    Archived Known Problems  . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
   <a href="#appendix-A.1">A.1</a>   Architectural  . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
   <a href="#appendix-A.1.1">A.1.1</a> Cannot specify multiple URIs for replicated resources  . . . <a href="#page-21">21</a>
   <a href="#appendix-A.1.2">A.1.2</a> Replica distance is unknown  . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
   <a href="#appendix-A.1.3">A.1.3</a> Proxy resource location  . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
   <a href="#appendix-A.2">A.2</a>   Implementation . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
   <a href="#appendix-A.2.1">A.2.1</a> Use of Cache-Control headers . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
   <a href="#appendix-A.2.2">A.2.2</a> Lack of HTTP/1.1 compliance for caching proxies  . . . . . . <a href="#page-24">24</a>
   <a href="#appendix-A.2.3">A.2.3</a> ETag support . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a>
   <a href="#appendix-A.2.4">A.2.4</a> Servers and content should be optimized for caching  . . . . <a href="#page-26">26</a>
   <a href="#appendix-A.3">A.3</a>   Administration . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
   <a href="#appendix-A.3.1">A.3.1</a> Lack of fine-grained, standardized hierarchy controls  . . . <a href="#page-27">27</a>
   <a href="#appendix-A.3.2">A.3.2</a> Proxy/Server exhaustive log format standard for analysis . . <a href="#page-27">27</a>
   <a href="#appendix-A.3.3">A.3.3</a> Trace log timestamps . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
   <a href="#appendix-A.3.4">A.3.4</a> Exchange format for log summaries  . . . . . . . . . . . . . <a href="#page-29">29</a>
         Full Copyright Statement . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>

   This memo discusses problems with proxies - which act as
   application-level intermediaries for Web requests - and more
   specifically with caching proxies, which retain copies of previously
   requested resources in the hope of improving overall quality of
   service by serving the content locally.  Commonly used terminology in
   this memo can be found in the "Internet Web Replication and Caching
   Taxonomy"[<a href="#ref-2" title="&quot;Internet Web Replication and Caching Taxonomy&quot;">2</a>].

   No individual or organization has complete knowledge of the known
   problems in Web caching, and the editors are grateful to the
   contributors to this document.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a> Problem Template</span>

   A common problem template is used within the following sections.  We
   gratefully acknowledge <a href="./rfc2525">RFC2525</a> [<a href="#ref-1" title="&quot;Known TCP Implementation Problems&quot;">1</a>] which helped define an initial
   format for this known problems list.  The template format is
   summarized in the following table and described in more detail below.

      Name:           short, descriptive name of the problem (3-5 words)
      Classification: classifies the problem: performance, security, etc
      Description:    describes the problem succinctly
      Significance:   magnitude of problem, environments where it exists
      Implications:   the impact of the problem on systems and networks
      See Also:       a reference to a related known problem
      Indications:    states how to detect the presence of this problem



<span class="grey">Cooper &amp; Dilley              Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


      Solution(s):    describe the solution(s) to this problem, if any
      Workaround:     practical workaround for the problem
      References:     information about the problem or solution
      Contact:        contact name and email address for this section

   Name
      A short, descriptive, name (3-5 words) name associated with the
      problem.

   Classification
      Problems are grouped into categories of similar problems for ease
      of reading of this memo.  Choose the category that best describes
      the problem.  The suggested categories include three general
      categories and several more specific categories.

      *  Architecture: the fundamental design is incomplete, or
         incorrect

      *  Specification: the spec is ambiguous, incomplete, or incorrect.

      *  Implementation: the implementation of the spec is incorrect.

      *  Performance: perceived page response at the client is
         excessive; network bandwidth consumption is excessive; demand
         on origin or proxy servers exceed reasonable bounds.

      *  Administration: care and feeding of caches is, or causes, a
         problem.

      *  Security: privacy, integrity, or authentication concerns.

   Description
      A definition of the problem, succinct but including necessary
      background information.

   Significance (High, Medium, Low)
      May include a brief summary of the environments for which the
      problem is significant.

   Implications
      Why the problem is viewed as a problem.  What inappropriate
      behavior results from it? This section should substantiate the
      magnitude of any problem indicated with High significance.

   See Also
      Optional.  List of other known problems that are related to this
      one.




<span class="grey">Cooper &amp; Dilley              Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


   Indications
      How to detect the presence of the problem.  This may include
      references to one or more substantiating documents that
      demonstrate the problem.  This should include the network
      configuration that led to the problem such that it can be
      reproduced.  Problems that are not reproducible will not appear in
      this memo.

   Solution(s)
      Solutions that permanently fix the problem, if such are known. For
      example, what version of the software does not exhibit the
      problem?  Indicate if the solution is accepted by the community,
      one of several solutions pending agreement, or open possibly with
      experimental solutions.

   Workaround
      Practical workaround if no solution is available or usable.  The
      workaround should have sufficient detail for someone experiencing
      the problem to get around it.

   References
      References to related information in technical publications or on
      the web.  Where can someone interested in learning more go to find
      out more about this problem, its solution, or workarounds?

   Contact
      Contact name and email address of the person who supplied the
      information for this section.  The editors are listed as contacts
      for anonymous submissions.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Known Problems</span>

   The remaining sections of this document present the currently
   documented known problems.  The problems are ordered by
   classification and significance.  Issues with protocol specification
   or architecture are first, followed by implementation issues.  Issues
   of high significance are first, followed by lower significance.

   Some of the problems initially identified in the previous versions of
   this document have been moved to <a href="#appendix-A">Appendix A</a> since they discuss issues
   where resolution primarily involves education rather than protocol
   work.

   A full list of the problems is available in the table of contents.







<span class="grey">Cooper &amp; Dilley              Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> Known Specification Problems</span>

<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a> Vary header is underspecified and/or misleading</span>

   Name
      The "Vary" header is underspecified and/or misleading

   Classification
      Specification

   Description
      The Vary header in HTTP/1.1 was designed to allow a caching proxy
      to safely cache responses even if the server's choice of variants
      is not entirely understood.  As <a href="./rfc2616">RFC 2616</a> says:

         The Vary header field can be used to express the parameters the
         server uses to select a representation that is subject to
         server-driven negotiation.

      One might expect that this mechanism is useful in general for
      extensions that change the response message based on some aspects
      of the request.  However, that is not true.

      During the design of the HTTP delta encoding specification[9] it
      was realized that an HTTP/1.1 proxy that does not understand delta
      encoding might cache a delta-encoded response and then later
      deliver it to a non-delta-capable client, unless the extension
      included some mechanism to prevent this.  Initially, it was
      thought that Vary would suffice, but the following scenario proves
      this wrong.

      NOTE: It is likely that other scenarios exhibiting the same basic
      problem with "Vary" could be devised, without reference to delta
      encoding.  This is simply a concrete scenario used to explain the
      problem.

      A complete description of the IM and A-IM headers may be found in
      the "Delta encoding in HTTP" specification.  For the purpose of
      this problem description, the relevant details are:

      1. The concept of an "instance manipulation" is introduced.  In
         some ways, this is similar to a content-coding, but there are
         differences.  One example of an instance manipulation name is
         "vcdiff".

      2. A client signals its willingness to accept one or more
         instance-manipulations using the A-IM header.




<span class="grey">Cooper &amp; Dilley              Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


      3. A server indicates which instance-manipulations are used to
         encode the body of a response using the IM header.

      4. Existing implementations will ignore the A-IM and IM headers,
         following the usual HTTP rules for handling unknown headers.

      5. Responses encoded with an instance-manipulation are sent using
         the (proposed) 226 status code, "IM Used".

      6. In response to a conditional request that carries an IM header,
         if the request-URI has been modified then a server may transmit
         a compact encoding of the modifications using a delta-encoding
         instead of a status-200 response.  The encoded response cannot
         be understood by an implementation that does not support delta
         encodings.

      This summary omits many details.

      Suppose client A sends this request via proxy P:

         GET http://example.com/foo.html HTTP/1.1
         Host: example.com
         If-None-Match: "abc"
         A-IM: vcdiff

      and the origin server returns, via P, this response:

         HTTP/1.1 226 IM Used
         Etag: "def"
         Date: Wed, 19 Apr 2000 18:46:13 GMT
         IM: vcdiff
         Cache-Control: max-age-60
         Vary: A-IM, If-None-Match

      the body of which is a delta-encoded response (it encodes the
      difference between the Etag "abc" instance of foo.html, and the
      "def" instance).  Assume that P stores this response in its cache,
      and that P does not understand the vcdiff encoding.

      Later, client B, also ignorant of delta-encoding, sends this
      request via P:

         GET http://example.com/foo.html HTTP/1.1
         Host: example.com

      What can P do now?  According to the specification for the Vary
      header in <a href="./rfc2616">RFC2616</a>,




<span class="grey">Cooper &amp; Dilley              Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


         The Vary field value indicates the set of request-header fields
         that fully determines, while the response is fresh, whether a
         cache is permitted to use the response to reply to a subsequent
         request without revalidation.

      Implicitly, however, the cache would be allowed to use the stored
      response in response to client B WITH "revalidation".  This is the
      potential bug.

      An obvious implementation of the proxy would send this request to
      test whether its cache entry is fresh (i.e., to revalidate the
      entry):

         GET /foo.html HTTP/1.1
         Host: example.com
         If-None-Match: "def"

      That is, the proxy simply forwards the new request, after doing
      the usual transformation on the URL and tacking on the "obvious"
      If-None-Match header.

      If the origin server's Etag for the current instance is still
      "def", it would naturally respond:

         HTTP/1.1 304 Not Modified
         Etag: "def"
         Date: Wed, 19 Apr 2000 18:46:14 GMT

      thus telling the proxy P that it can use its stored response.  But
      this cache response actually involves a delta-encoding that would
      not be sensible to client B, signaled by a header field that would
      be ignored by B, and so the client displays garbage.

      The problem here is that the original request (from client A)
      generated a response that is not sensible to client B, not merely
      one that is not "the appropriate representation" (as the result of
      server-driven negotiation).

      One might argue that the proxy P shouldn't be storing status-226
      responses in the first place.  True in theory, perhaps, but
      unfortunately <a href="./rfc2616#section-13.4">RFC2616, section&nbsp;13.4</a>, says:

         A response received with any [status code other than 200, 203,
         206, 300, 301 or 410] MUST NOT be returned in a reply to a
         subsequent request unless there are cache-control directives or
         another header(s) that explicitly allow it.  For example, these





<span class="grey">Cooper &amp; Dilley              Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


         include the following: an Expires header (<a href="#section-14.21">section 14.21</a>); a
         "max-age", "s-maxage", "must-revalidate", "proxy-revalidate",
         "public" or "private" cache-control directive (<a href="#section-14.9">section 14.9</a>).

      In other words, the specification allows caching of responses with
      yet-to-be-defined status codes if the response carries a plausible
      Cache-Control directive.  So unless we ban servers implementing
      this kind of extension from using these Cache-Control directives
      at all, the Vary header just won't work.

   Significance
      Medium

   Implications
      Certain plausible extensions to the HTTP/1.1 protocol might not
      interoperate correctly with older HTTP/1.1 caches, if the
      extensions depend on an interpretation of Vary that is not the
      same as is used by the cache implementer.

      This would have the effect either of causing hard-to-debug cache
      transparency failures, or of discouraging the deployment of such
      extensions, or of encouraging the implementers of such extensions
      to disable caching entirely.

   Indications
      The problem is visible when hand-simulating plausible message
      exchanges, especially when using the proposed delta encoding
      extension.  It probably has not been visible in practice yet.

   Solution(s)

      1. <a href="#section-13.4">Section 13.4</a> of the HTTP/1.1 specification should probably be
         changed to prohibit caching of responses with status codes that
         the cache doesn't understand, whether or not they include
         Expires headers and the like.  (It might require some care to
         define what "understands" means, leaving room for future
         extensions with new status codes.)  The behavior in this case
         needs to be defined as equivalent to "Cache-Control:  no-store"
         rather than "no-cache", since the latter allows revalidation.

         Possibly the specification of Vary should require that it be
         treated as "Cache-Control:  no-store" whenever the status code
         is unknown - that should solve the problem in the scenario
         given here.







<span class="grey">Cooper &amp; Dilley              Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


      2. Designers of HTTP/1.1 extensions should consider using
         mechanisms other than Vary to prevent false caching.

         It is not clear whether the Vary mechanism is widely
         implemented in caches; if not, this favors solution #1.

   Workaround
      A cache could treat the presence of a Vary header in a response as
      an implicit "Cache-control: no-store", except for "known" status
      codes, even though this is not required by <a href="./rfc2616">RFC 2616</a>.  This would
      avoid any transparency failures.  "Known status codes" for basic
      HTTP/1.1 caches probably include: 200, 203, 206, 300, 301, 410
      (although this list should be re-evaluated in light of the problem
      discussed here).

   References
      See [<a href="#ref-9" title="&quot;HTTP Delta in HTTP&quot;">9</a>] for the specification of the delta encoding extension, as
      well as for an example of the use of a Cache-Control extension
      instead of "Vary."

   Contact
      Jeff Mogul &lt;mogul@pa.dec.com&gt;

<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a> Client Chaining Loses Valuable Length Meta-Data</span>

   Name
      Client Chaining Loses Valuable Length Meta-Data

   Classification
      Performance

   Description
      HTTP/1.1[3] implementations are prohibited from sending Content-
      Length headers with any message whose body has been Transfer-
      Encoded.  Because 1.0 clients cannot accept chunked Transfer-
      Encodings, receiving 1.1 implementations must forward the body to
      1.0 clients must do so without the benefit of information that was
      discarded earlier in the chain.

   Significance
      Low

   Implications
      Lacking either a chunked transfer encoding or Content-Length
      indication creates negative performance implications for how the
      proxy must forward the message body.





<span class="grey">Cooper &amp; Dilley              Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


      In the case of response bodies, the server may either forward the
      response while closing the connection to indicate the end of the
      response or must utilize store and forward semantics to buffer the
      entire response in order to calculate a Content-Length.  The
      former option defeats the performance benefits of persistent
      connections in HTTP/1.1 (and their Keep-Alive cousin in HTTP/1.0)
      as well as creating some ambiguously lengthed responses.  The
      latter store and forward option may not even be feasible given the
      size of the resource and it will always introduce increased
      latency.

      Request bodies must undertake the store and forward process as 1.0
      request bodies must be delimited by Content-Length headers.  As
      with response bodies this may place unacceptable resource
      constraints on the proxy and the request may not be able to be
      satisfied.

   Indications
      The lack of HTTP/1.0 style persistent connections between 1.0
      clients and 1.1 proxies, only when accessing 1.1 servers, is a
      strong indication of this problem.

   Solution(s)
      An HTTP specification clarification that would allow origin known
      identity document Content-Lengths to be carried end to end would
      alleviate this issue.

   Workaround
      None.

   Contact
      Patrick McManus &lt;mcmanus@AppliedTheory.com&gt;

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> Known Architectural Problems</span>

<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a> Interception proxies break client cache directives</span>

   Name
      Interception proxies break client cache directives

   Classification
      Architecture

   Description
      HTTP[3] is designed for the user agent to be aware if it is
      connected to an origin server or to a proxy.  User agents
      believing they are transacting with an origin server but which are




<span class="grey">Cooper &amp; Dilley              Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


      really in a connection with an interception proxy may fail to send
      critical cache-control information they would have otherwise
      included in their request.

   Significance
      High

   Implications
      Clients may receive data that is not synchronized with the origin
      even when they request an end to end refresh, because of the lack
      of inclusion of either a "Cache-control: no-cache" or "must-
      revalidate" header.  These headers have no impact on origin server
      behavior so may not be included by the browser if it believes it
      is connected to that resource.  Other related data implications
      are possible as well.  For instance, data security may be
      compromised by the lack of inclusion of "private" or "no-store"
      clauses of the Cache-control header under similar conditions.

   Indications
      Easily detected by placing fresh (un-expired) content on a caching
      proxy while changing the authoritative copy, then requesting an
      end-to-end reload of the data through a proxy in both interception
      and explicit modes.

   Solution(s)
      Eliminate the need for interception proxies and IP spoofing, which
      will return correct context awareness to the client.

   Workaround
      Include relevant Cache-Control directives in every request at the
      cost of increased bandwidth and CPU requirements.

   Contact
      Patrick McManus &lt;mcmanus@AppliedTheory.com&gt;

<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a> Interception proxies prevent introduction of new HTTP methods</span>

   Name
      Interception proxies prevent introduction of new HTTP methods

   Classification
      Architecture

   Description
      A proxy that receives a request with a method unknown to it is
      required to generate an HTTP 501 Error as a response.  HTTP
      methods are designed to be extensible so there may be applications
      deployed with initial support just for the user agent and origin



<span class="grey">Cooper &amp; Dilley              Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


      server.  An interception proxy that hijacks requests which include
      new methods destined for servers that have implemented those
      methods creates a de-facto firewall where none may be intended.

   Significance
      Medium within interception proxy environments.

   Implications
      Renders new compliant applications useless unless modifications
      are made to proxy software.  Because new methods are not required
      to be globally standardized it is impossible to keep up to date in
      the general case.

   Solution(s)
      Eliminate the need for interception proxies.  A client receiving a
      501 in a traditional HTTP environment may either choose to repeat
      the request to the origin server directly, or perhaps be
      configured to use a different proxy.

   Workaround
      Level 5 switches (sometimes called Level 7 or application layer
      switches) can be used to keep HTTP traffic with unknown methods
      out of the proxy.  However, these devices have heavy buffering
      responsibilities, still require TCP sequence number spoofing, and
      do not interact well with persistent connections.

      The HTTP/1.1 specification allows a proxy to switch over to tunnel
      mode when it receives a request with a method or HTTP version it
      does not understand how to handle.

   Contact
      Patrick McManus &lt;mcmanus@AppliedTheory.com&gt;
      Henrik Nordstrom &lt;hno@hem.passagen.se&gt; (HTTP/1.1 clarification)

<span class="h4"><a class="selflink" id="section-2.2.3" href="#section-2.2.3">2.2.3</a> Interception proxies break IP address-based authentication</span>

   Name
      Interception proxies break IP address-based authentication

   Classification
      Architecture

   Description
      Some web servers are not open for public access, but restrict
      themselves to accept only requests from certain IP address ranges
      for security reasons.  Interception proxies alter the source
      (client) IP addresses to that of the proxy itself, without the




<span class="grey">Cooper &amp; Dilley              Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


      knowledge of the client/user.  This breaks such authentication
      mechanisms and prohibits otherwise allowed clients access to the
      servers.

   Significance
      Medium

   Implications
      Creates end user confusion and frustration.

   Indications
      Users  may start to see refused connections to servers after
      interception proxies are deployed.

   Solution(s)
      Use user-based authentication instead of (IP) address-based
      authentication.

   Workaround
      Using IP filters at the intercepting device (L4 switch) and bypass
      all requests to such servers concerned.

   Contact
      Keith K. Chau &lt;keithc@unitechnetworks.com&gt;

<span class="h4"><a class="selflink" id="section-2.2.4" href="#section-2.2.4">2.2.4</a> Caching proxy peer selection in heterogeneous networks</span>

   Name
      Caching proxy peer selection in heterogeneous networks

   Classification
      Architecture

   Description
      ICP[4] based caching proxy peer selection in networks with large
      variance in latency and bandwidth between peers can lead to non-
      optimal peer selection.  For example take Proxy C with two
      siblings, Sib1 and Sib2, and the following network topology
      (summarized).

      *  Cache C's link to Sib1, 2 Mbit/sec with 300 msec latency

      *  Cache C's link to Sib2, 64 Kbit/sec with 10 msec latency.

      ICP[4] does not work well in this context.  If a user submits a
      request to Proxy C for page P that results in a miss, C will send
      an ICP request to Sib1 and Sib2.  Assume both siblings have the




<span class="grey">Cooper &amp; Dilley              Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


      requested object P.  The ICP_HIT reply will always come from Sib2
      before Sib1.  However, it is clear that the retrieval of large
      objects will be faster from Sib1, rather than Sib2.

      The problem is more complex because Sib1 and Sib2 can't have a
      100% hit ratio.  With a hit rate of 10%, it is more efficient to
      use Sib1 with resources larger than 48K.  The best choice depends
      on at least the hit rate and link characteristics; maybe other
      parameters as well.

   Significance
      Medium

   Implications
      By using the first peer to respond, peer selection algorithms are
      not optimizing retrieval latency to end users.  Furthermore they
      are causing more work for the high-latency peer since it must
      respond to such requests but will never be chosen to serve content
      if the lower latency peer has a copy.

   Indications
      Inherent in design of ICP v1, ICP v2, and any cache mesh protocol
      that selects peers based upon first response.

      This problem is not exhibited by cache digest or other protocols
      which (attempt to) maintain knowledge of peer contents and only
      hit peers that are believed to have a copy of the requested page.

   Solution(s)
      This problem is architectural with the peer selection protocols.

   Workaround
      Cache mesh design when using such a protocol should be done in
      such a way that there is not a high latency variance among peers.
      In the example presented in the above description the high latency
      high bandwidth peer could be used as a parent, but should not be
      used as a sibling.

   Contact
      Ivan Lovric &lt;ivan.lovric@cnet.francetelecom.fr&gt;
      John Dilley &lt;jad@akamai.com&gt;










<span class="grey">Cooper &amp; Dilley              Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


<span class="h4"><a class="selflink" id="section-2.2.5" href="#section-2.2.5">2.2.5</a> ICP Performance</span>

   Name
      ICP performance

   Classification
      Architecture(ICP), Performance

   Description
      ICP[4] exhibits O(n^2) scaling properties, where n is the number
      of participating peer proxies.  This can lead ICP traffic to
      dominate HTTP traffic within a network.

   Significance
      Medium

   Implications
      If a proxy has many ICP peers the bandwidth demand of ICP can be
      excessive.  System managers must carefully regulate ICP peering.
      ICP also leads proxies to become homogeneous in what they serve;
      if your proxy does not have a document it is unlikely your peers
      will have it either.  Therefore, ICP traffic requests are largely
      unable to locate a local copy of an object (see [<a href="#ref-6" title="&quot;Relation Analysis, Cache Meshes&quot;">6</a>]).

   Indications
      Inherent in design of ICP v1, ICP v2.

   Solution(s)
      This problem is architectural - protocol redesign or replacement
      is required to solve it if ICP is to continue to be used.

   Workaround
      Implementation workarounds exist, for example to turn off use of
      ICP, to carefully regulate peering, or to use another mechanism if
      available, such as cache digests.  A cache digest protocol shares
      a summary of cache contents using a Bloom Filter technique.  This
      allows a cache to estimate whether a peer has a document.  Filters
      are updated regularly but are not always up-to-date so cannot help
      when a spike in popularity occurs.  They also increase traffic but
      not as much as ICP.

      Proxy clustering protocols organize proxies into a mesh provide
      another alternative solution.  There is ongoing research on this
      topic.

   Contact
      John Dilley &lt;jad@akamai.com&gt;




<span class="grey">Cooper &amp; Dilley              Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


<span class="h4"><a class="selflink" id="section-2.2.6" href="#section-2.2.6">2.2.6</a> Caching proxy meshes can break HTTP serialization of content</span>

   Name
      Caching proxy meshes can break HTTP serialization of content

   Classification
      Architecture (HTTP protocol)

   Description
      A caching proxy mesh where a request may travel different paths,
      depending on the state of the mesh and associated caches, can
      break HTTP content serialization, possibly causing the end user to
      receive older content than seen on an earlier request, where the
      request traversed another path in the mesh.

   Significance
      Medium

   Implications
      Can cause end user confusion.  May in some situations (sibling
      cache hit, object has changed state from cacheable to uncacheable)
      be close to impossible to get the caches properly updated with the
      new content.

   Indications
      Older content is unexpectedly returned from a caching proxy mesh
      after some time.

   Solutions(s)
      Work with caching proxy vendors and researchers to find a suitable
      protocol for maintaining proxy relations and object state in a
      mesh.

   Workaround
      When designing a hierarchy/mesh, make sure that for each end-
      user/URL combination there is only one single path in the mesh
      during normal operation.

   Contact
      Henrik Nordstrom &lt;hno@hem.passagen.se&gt;











<span class="grey">Cooper &amp; Dilley              Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a> Known Implementation Problems</span>

<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a> User agent/proxy failover</span>

   Name
      User agent/proxy failover

   Classification
      Implementation

   Description
      Failover between proxies at the user agent (using a proxy.pac[8]
      file) is erratic and no standard behavior is defined.
      Additionally, behavior is hard-coded into the browser, so that
      proxy administrators cannot use failover at the user agent
      effectively.

   Significance
      Medium

   Implications
      Architects are forced to implement failover at the proxy itself,
      when it may be more appropriate and economical to do it within the
      user agent.

   Indications
      If a browser detects that its primary proxy is down, it will wait
      n minutes before trying the next one it is configured to use.  It
      will then wait y minutes before asking the user if they'd like to
      try the original proxy again.  This is very confusing for end
      users.

   Solution(s)
      Work with browser vendors to establish standard extensions to
      JavaScript proxy.pac libraries that will allow configuration of
      these timeouts.

   Workaround
      User education; redundancy at the proxy level.

   Contact
      Mark Nottingham &lt;mnot@mnot.net&gt;









<span class="grey">Cooper &amp; Dilley              Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a> Some servers send bad Content-Length headers for files that</span>
<span class="h4">      contain CR</span>

   Name
      Some servers send bad Content-Length headers for files that
      contain CR

   Classification
      Implementation

   Description
      Certain web servers send a Content-length value that is larger
      than number of bytes in the HTTP message body.  This happens when
      the server strips off CR characters from text files with lines
      terminated with CRLF as the file is written to the client.  The
      server probably uses the stat() system call to get the file size
      for the Content-Length header.  Servers that exhibit this behavior
      include the GN Web server (version 2.14 at least).

   Significance
      Low.  Surveys indicate only a small number of sites run faulty
      servers.

   Implications
      In this case, an HTTP client (e.g., user agent or proxy) may
      believe it received a partial response.  HTTP/1.1 [<a href="#ref-3" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">3</a>] advises that
      caches MAY store partial responses.

   Indications
      Count the number of bytes in the message body and compare to the
      Content-length value.  If they differ the server exhibits this
      problem.

   Solutions
      Upgrade or replace the buggy server.

   Workaround
      Some browsers and proxies use one TCP connection per object and
      ignore the Content-Length.  The document end of file is identified
      by the close of the TCP socket.

   Contact
      Duane Wessels &lt;wessels@measurement-factory.com&gt;

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Security Considerations</span>

   This memo does not raise security considerations in itself.  See the
   individual submissions for details of security concerns and issues.



<span class="grey">Cooper &amp; Dilley              Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


References

   [<a id="ref-1">1</a>]  Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J.,
        Heavens, I., Lahey, K., Semke, J. and B. Volz, "Known TCP
        Implementation Problems", <a href="./rfc2525">RFC 2525</a>, March 1999.

   [<a id="ref-2">2</a>]  Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
        Replication and Caching Taxonomy", <a href="./rfc3040">RFC 3040</a>, January 2001.

   [<a id="ref-3">3</a>]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.

   [<a id="ref-4">4</a>]  Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
        Version 2", <a href="./rfc2186">RFC 2186</a>, September 1997.

   [<a id="ref-5">5</a>]  Davison, B., "Web Traffic Logs: An Imperfect Resource for
        Evaluation", in Proceedings of the Ninth Annual Conference of
        the Internet Society (INET'99), July 1999.

   [<a id="ref-6">6</a>]  Melve, I., "Relation Analysis, Cache Meshes", in Proceedings of
        the 3rd International WWW Caching Workshop, June 1998,
        &lt;<a href="http://wwwcache.ja.net/events/workshop/29/magicnumber.html">http://wwwcache.ja.net/events/workshop/29/magicnumber.html</a>&gt;.

   [<a id="ref-7">7</a>]  Krishnamurthy, B. and M. Arlett, "PRO-COW: Protocol Compliance
        on the Web", AT&amp;T Labs Technical Report #990803-05-TM, August
        1999, &lt;<a href="http://www.research.att.com/~bala/papers/procow-1.ps.gz">http://www.research.att.com/~bala/papers/procow-1.ps.gz</a>&gt;.

   [<a id="ref-8">8</a>]  Netscape, Inc., "Navigator Proxy Auto-Config File Format", March
        1996,
        <a href="http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html">http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-</a>
        <a href="http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html">live.html</a>

   [<a id="ref-9">9</a>]  Mogul, J., Krishnamurthy, B., Douglis, F., Feldmann, A., Goland,
        Y., van Hoff, A. and D. Hellerstein, "HTTP Delta in HTTP", Work
        in Progress.















<span class="grey">Cooper &amp; Dilley              Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


Authors' Addresses

   Ian Cooper
   Equinix, Inc.
   2450 Bayshore Parkway
   Mountain View, CA  94043
   USA

   Phone: +1 650 316 6065
   EMail: icooper@equinix.com


   John Dilley
   Akamai Technologies, Inc.
   1400 Fashion Island Blvd
   Suite 703
   San Mateo, CA  94404
   USA

   Phone: +1 650 627 5244
   EMail: jad@akamai.com






























<span class="grey">Cooper &amp; Dilley              Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Archived Known Problems</span>

   The following sub-sections are an archive of problems identified in
   the initial production of this memo.  These are typically problems
   requiring further work/research, or user education.  They are
   included here for reference purposes only.

<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a> Architectural</span>

<span class="h4"><a class="selflink" id="appendix-A.1.1" href="#appendix-A.1.1">A.1.1</a> Cannot specify multiple URIs for replicated resources</span>

   Name
      Cannot specify multiple URIs for replicated resources

   Classification
      Architecture

   Description
      There is no way to specify that multiple URIs may be used for a
      single resource, one for each replica of the resource.  Similarly,
      there is no way to say that some set of proxies (each identified
      by a URI) may be used to resolve a URI.

   Significance
      Medium

   Implications
      Forces users to understand the replication model and mechanism.
      Makes it difficult to create a replication framework without
      protocol support for replication and naming.

   Indications
      Inherent in HTTP/1.0, HTTP/1.1.

   Solution(s)
      Architectural - protocol design is necessary.

   Workaround
      Replication mechanisms force users to locate a replica or mirror
      site for replicated content.

   Contact
      Daniel LaLiberte &lt;liberte@w3.org&gt;








<span class="grey">Cooper &amp; Dilley              Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


<span class="h4"><a class="selflink" id="appendix-A.1.2" href="#appendix-A.1.2">A.1.2</a> Replica distance is unknown</span>

   Name
      Replica distance is unknown

   Classification
      Architecture

   Description
      There is no recommended way to find out which of several servers
      or proxies is closer either to the requesting client or to another
      machine, either geographically or in the network topology.

   Significance
      Medium

   Implications
      Clients must guess which replica is closer to them when requesting
      a copy of a document that may be served from multiple locations.
      Users must know the set of servers that can serve a particular
      object.  This in general is hard to determine and maintain.  Users
      must understand network topology in order to choose the closest
      copy.  Note that the closest copy is not always the one that will
      result in quickest service.  A nearby but heavily loaded server
      may be slower than a more distant but lightly loaded server.

   Indications
      Inherent in HTTP/1.0, HTTP/1.1.

   Solution(s)
      Architectural - protocol work is necessary.  This is a specific
      instance of a general problem in widely distributed systems.  A
      general solution is unlikely, however a specific solution in the
      web context is possible.

   Workaround
      Servers can (many do) provide location hints in a replica
      selection web page.  Users choose one based upon their location.
      Users can learn which replica server gives them best performance.
      Note that the closest replica geographically is not necessarily
      the closest in terms of network topology.  Expecting users to
      understand network topology is unreasonable.

   Contact
      Daniel LaLiberte &lt;liberte@w3.org&gt;






<span class="grey">Cooper &amp; Dilley              Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


<span class="h4"><a class="selflink" id="appendix-A.1.3" href="#appendix-A.1.3">A.1.3</a> Proxy resource location</span>

   Name
      Proxy resource location

   Classification
      Architecture

   Description
      There is no way for a client or server (including another proxy)
      to inform a proxy of an alternate address (perhaps including the
      proxy to use to reach that address) to use to fetch a resource.
      If the client does not trust where the redirected resource came
      from, it may need to validate it or validate where it came from.

   Significance
      Medium

   Implications
      Proxies have no systematic way to locate resources within other
      proxies or origin servers.  This makes it more difficult to share
      information among proxies.  Information sharing would improve
      global efficiency.

   Indications
      Inherent in HTTP/1.0, HTTP/1.1.

   Solution(s)
      Architectural - protocol design is necessary.

   Workaround
      Certain proxies share location hints in the form of summary
      digests of their contents (e.g., Squid).  Certain proxy protocols
      enable a proxy query another for its contents (e.g., ICP).  (See
      however "ICP  Performance" issue (<a href="#section-2.2.5">Section 2.2.5</a>).)

   Contact
      Daniel LaLiberte &lt;liberte@w3.org&gt;

<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a> Implementation</span>

<span class="h4"><a class="selflink" id="appendix-A.2.1" href="#appendix-A.2.1">A.2.1</a> Use of Cache-Control headers</span>

   Name
      Use of Cache-Control headers

   Classification
      Implementation



<span class="grey">Cooper &amp; Dilley              Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


   Description
      Many (if not most) implementations incorrectly interpret Cache-
      Control response headers.

   Significance
      High

   Implications
      Cache-Control headers will be spurned by end users if there are
      conflicting or non-standard implementations.

   Indications
      -

   Solution(s)
      Work with vendors and others to assure proper application

   Workaround
      None.

   Contact
      Mark Nottingham &lt;mnot@mnot.net&gt;

<span class="h4"><a class="selflink" id="appendix-A.2.2" href="#appendix-A.2.2">A.2.2</a> Lack of HTTP/1.1 compliance for caching proxies</span>

   Name
      Lack of HTTP/1.1 compliance for caching proxies

   Classification
      Implementation

   Description
      Although performance benchmarking of caches is starting to be
      explored, protocol compliance is just as important.

   Significance
      High

   Implications
      Caching proxy vendors implement their interpretation of the
      specification; because the specification is very large, sometimes
      vague and ambiguous, this can lead to inconsistent behavior
      between caching proxies.

      Caching proxies need to comply to the specification (or the
      specification needs to change).





<span class="grey">Cooper &amp; Dilley              Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


   Indications
      There is no currently known compliance test being used.

      There is work underway to quantify how closely servers comply with
      the current specification.  A joint technical report between AT&amp;T
      and HP Labs [<a href="#ref-7" title="&quot;PRO-COW: Protocol Compliance on the Web&quot;">7</a>] describes the compliance testing.  This report
      examines how well each of a set of top traffic-producing sites
      support certain HTTP/1.1 features.

      The Measurement Factory (formerly IRCache) is working to develop
      protocol compliance testing software.  Running such a conformance
      test suite against caching proxy products would measure compliance
      and ultimately would help assure they comply to the specification.

   Solution(s)
      Testing should commence and be reported in an open industry forum.
      Proxy implementations should conform to the specification.

   Workaround
      There is no workaround for non-compliance.

   Contact
      Mark Nottingham &lt;mnot@mnot.net&gt;
      Duane Wessels &lt;wessels@measurement-factory.com&gt;

<span class="h4"><a class="selflink" id="appendix-A.2.3" href="#appendix-A.2.3">A.2.3</a> ETag support</span>

   Name
      ETag support

   Classification
      Implementation

   Description
      Available caching proxies appear not to support ETag (strong)
      validation.

   Significance
      Medium

   Implications
      Last-Modified/If-Modified-Since validation is inappropriate for
      many requirements, both because of its weakness and its use of
      dates.  Lack of a usable, strong coherency protocol leads
      developers and end users not to trust caches.

   Indications
      -



<span class="grey">Cooper &amp; Dilley              Informational                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


   Solution(s)
      Work with vendors to implement ETags; work for better validation
      protocols.

   Workaround
      Use Last-Modified/If-Modified-Since validation.

   Contact
      Mark Nottingham &lt;mnot@mnot.net&gt;

<span class="h4"><a class="selflink" id="appendix-A.2.4" href="#appendix-A.2.4">A.2.4</a> Servers and content should be optimized for caching</span>

   Name
      Servers and content should be optimized for caching

   Classification
      Implementation (Performance)

   Description
      Many web servers and much web content could be implemented to be
      more conducive to caching, reducing bandwidth demand and page load
      delay.

   Significance
      Medium

   Implications
      By making poor use of caches, origin servers encourage longer load
      times, greater load on caching proxies, and increased network
      demand.

   Indications
      The problem is most apparent for pages that have low or zero
      expires time, yet do not change.

   Solution(s)
      -

   Workaround
      Servers could start using unique object identifiers for write-only
      content: if an object changes it gets a new name, otherwise it is
      considered to be immutable and therefore have an infinite expire
      age.  Certain hosting providers do this already.

   Contact
      Peter Danzig





<span class="grey">Cooper &amp; Dilley              Informational                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a> Administration</span>

<span class="h4"><a class="selflink" id="appendix-A.3.1" href="#appendix-A.3.1">A.3.1</a> Lack of fine-grained, standardized hierarchy controls</span>

   Name
      Lack of fine-grained, standardized hierarchy controls

   Classification
      Administration

   Description
      There is no standard for instructing a proxy as to how it should
      resolve the parent to fetch a given object from.  Implementations
      therefore vary greatly, and it can be difficult to make them
      interoperate correctly in a complex environment.

   Significance
      Medium

   Implications
      Complications in deployment of caches in a complex network
      (especially corporate networks)

   Indications
      Inability of some proxies to be configured to direct traffic based
      on domain name, reverse lookup IP address, raw IP address, in
      normal operation and in failover mode.  Inability in some proxies
      to set a preferred parent / backup parent configuration.

   Solution(s)
      -

   Workaround
      Work with vendors to establish an acceptable configuration within
      the limits of their product; standardize on one product.

   Contact
      Mark Nottingham &lt;mnot@mnot.net&gt;

<span class="h4"><a class="selflink" id="appendix-A.3.2" href="#appendix-A.3.2">A.3.2</a> Proxy/Server exhaustive log format standard for analysis</span>

   Name
      Proxy/Server exhaustive log format standard for analysis

   Classification
      Administration





<span class="grey">Cooper &amp; Dilley              Informational                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


   Description
      Most proxy or origin server logs used for characterization or
      evaluation do not provide sufficient detail to determine
      cacheability of responses.

   Significance
      Low (for operationality; high significance for research efforts)

   Implications
      Characterizations and simulations are based on non-representative
      workloads.

   See Also
      W3C Web Characterization Activity, since they are also concerned
      with collecting high quality logs and building characterizations
      from them.

   Indications
      -

   Solution(s)
      To properly clean and to accurately determine cacheability of
      responses, a complete log is required (including all request
      headers as well as all response headers such as "User-agent" [for
      removal of spiders] and "Expires", "max-age", "Set-cookie", "no-
      cache", etc.)

   Workaround
      -

   References
      See "Web Traffic Logs: An Imperfect Resource for Evaluation"[<a href="#ref-5" title="&quot;Web Traffic Logs: An Imperfect Resource for Evaluation&quot;">5</a>]
      for some discussion of this.

   Contact
      Brian D. Davison &lt;davison@acm.org&gt;
      Terence Kelly &lt;tpkelly@eecs.umich.edu&gt;

<span class="h4"><a class="selflink" id="appendix-A.3.3" href="#appendix-A.3.3">A.3.3</a> Trace log timestamps</span>

   Name
      Trace log timestamps

   Classification
      Administration






<span class="grey">Cooper &amp; Dilley              Informational                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


   Description
      Some proxies/servers log requests without sufficient timing
      detail.  Millisecond resolution is often too small to preserve
      request ordering and either the servers should record request
      reception time in addition to completion time, or elapsed time
      plus either one.

   Significance
      Low (for operationality; medium significance for research efforts)

   Implications
      Characterization and simulation fidelity is improved with accurate
      timing and ordering information.  Since logs are generally written
      in order of request completion, these logs cannot be re-played
      without knowing request generation times and reordering
      accordingly.

   See Also
      -

   Indications
      Timestamps can be identical for multiple entries (when only
      millisecond resolution is used).  Request orderings can be jumbled
      when clients open additional connections for embedded objects
      while still receiving the container object.

   Solution(s)
      Since request completion time is common (e.g., Squid), recommend
      continuing to use it (with microsecond resolution if possible)
      plus recording elapsed time since request reception.

   Workaround
      -

   References
      See "Web Traffic Logs: An Imperfect Resource for Evaluation"[<a href="#ref-5" title="&quot;Web Traffic Logs: An Imperfect Resource for Evaluation&quot;">5</a>]
      for some discussion of this.

   Contact
      Brian D. Davison &lt;davison@acm.org&gt;

<span class="h4"><a class="selflink" id="appendix-A.3.4" href="#appendix-A.3.4">A.3.4</a> Exchange format for log summaries</span>

   Name
      Exchange format for log summaries

   Classification
      Administration/Analysis?



<span class="grey">Cooper &amp; Dilley              Informational                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


   Description
      Although we have (more or less) a standard log file format for
      proxies (plain vanilla Common Logfile and Squid), there isn't a
      commonly accepted format for summaries of those log files.
      Summaries could be generated by the cache itself, or by post-
      processing existing log file formats such as Squid's.

   Significance
      High, since it means that each log file summarizing/analysis tool
      is essentially reinventing the wheel (un-necessary repetition of
      code), and the cost of processing a large number of large log
      files through a variety of analysis tools is (again for no good
      reason) excessive.

   Implications
      In order to perform a meaningful analysis (e.g., to measure
      performance in relation to loading/configuration over time) the
      access logs from multiple busy caches, it's often necessary to run
      first one tool then another, each against the entire log file (or
      a significantly large subset of the log).  With log files running
      into hundreds of MB even after compression (for a cache dealing
      with millions of transactions per day) this is a non-trivial task.

   See Also
      IP packet/header sniffing - it may be that individual transactions
      are at a level of granularity which simply isn't sensible to be
      attempting on extremely busy caches.  There may also be legal
      implications in some countries, e.g., if this analysis identifies
      individuals.

   Indications
      Disks/memory full(!) Stats (using multiple programs) take too long
      to run.  Stats crunching must be distributed out to multiple
      machines because of its high computational cost.

   Solution(s)
      Have the proxy produce a standardized summary of its activity
      either automatically or via an external (e.g., third party) tool,
      in a commonly agreed format.  The format could be something like
      XML or the Extended Common Logfile, but the format and contents
      are subjects for discussion.  Ideally this approach would permit
      individual cache server products to supply subsets of the possible
      summary info, since it may not be feasible for all servers to
      provide all of the information which people would like to see.







<span class="grey">Cooper &amp; Dilley              Informational                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


   Workaround
      Devise a private summary format for your own personal use - but
      this complicates or even precludes the exchange of summary info
      with other interested parties.

   References
      See the web pages for the commonly used cache stats analysis
      programs, e.g., Calamaris, squidtimes, squidclients, etc.

   Contact
      Martin Hamilton &lt;martin@wwwcache.ja.net&gt;








































<span class="grey">Cooper &amp; Dilley              Informational                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc3143">RFC 3143</a>           Known HTTP Proxy/Caching Problems           June 2001</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Cooper &amp; Dilley              Informational                     [Page 32]
</pre>