Subject: 24-hour old misses

From: Alex Rousskov <[email-masked]>
Date: Wed, 4 Sep 2002 10:56:09 -0600 (MDT)

Hi there,

	RFC 2616, Section 13.2.4 "Expiration Calculations" contains
the following MUST:

   The cache MUST attach Warning
   113 to any response whose age is more than 24 hours if such warning
   has not already been added.

The context of that MUST is expiration calculation and, hence, cache
hits. On the other hand, attaching a Warning to misses may help in
case there is a non-1.1-compliant cache upstream.

Did the author(s) intend for the above MUST to apply to HIT responses
only?

Thanks,

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

---

From: Diwakar Shetty <[email-masked]>
Date: Thu, 05 Sep 2002 10:25:27 +0530

I could understand the use of "&" in URL for HTTP requests

"&" separates the <name>=<value> pair

 However, what is the use of ";" in URLS for HTTP ?

 Thanks
 Diwakar

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 05 Sep 2002 12:26:54 -0400

> However, what is the use of ";" in URLS for HTTP ?

Semicolon is just another valid character in the path component
of a URL - it has no special significance.  When the Web was
being invented, VMS was an important platform, and the semicolon 
was used in VMS file names, so making it a legal path name
component was important.

--
Scott Lawrence                             
  <[email-masked]>

---

From: Yves Lafon <[email-masked]>
Date: Thu, 5 Sep 2002 19:29:22 +0200 (MET DST)

If it is in a path component, it means a parameter for that component:

>From http://www.ietf.org/rfc/rfc2396.txt

<<<<
3.3. Path Component

   The path component contains data, specific to the authority (or the
   scheme if there is no authority component), identifying the resource
   within the scope of that scheme and authority.

      path          = [ abs_path | opaque_part ]

      path_segments = segment *( "/" segment )
      segment       = *pchar *( ";" param )
      param         = *pchar

      pchar         = unreserved | escaped |
                      ":" | "@" | "&" | "=" | "+" | "$" | ","

   The path may consist of a sequence of path segments separated by a
   single slash "/" character.  Within a path segment, the characters
   "/", ";", "=", and "?" are reserved.  Each path segment may include a
   sequence of parameters, indicated by the semicolon ";" character.
   The parameters are not significant to the parsing of relative
   references.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

---

From: Diwakar Shetty <[email-masked]>
Date: Fri, 06 Sep 2002 10:01:53 +0530

Well, it seems like semicolon is equivalent to "&" in URL for HTTP Get
Method

i.e. ";" separates the <name>=<value> pair

Diwakar

Scott Lawrence wrote:

> of a URL - it has no special significance.

---

From: Jeffrey Mogul <[email-masked]>
Date: Fri, 27 Sep 2002 17:48:54 -0700

Catching up (slowly!) on old email:

Alex writes:

    

Again, I believe I wrote this part.

Take a look at section 14.46 (Warning) which defines the specific
warning-value mentioned above:

   113 Heuristic expiration
     MUST be included if the cache heuristically chose a freshness
     lifetime greater than 24 hours and the response's age is greater
     than 24 hours.

True, it's not explicit here that this applies only to cache
hits.  But it would only be interesting on a miss if the cache's
heuristic choice for a freshness lifetime were to be inserted
into the forwarded response header.  In other words, the origin
server sent no Expires header (or something equivalent, such
as a max-age directive) and the proxy guessed at one and then
added an Expires header to the response.

But look at section 13.5.2 (Non-modifiable Headers), which says
that

   A transparent proxy MUST NOT modify [the Expires field in
   a response, but MAY add one] if not already present. If an
   Expires header is added, it MUST be given a field-value identical to
   that of the Date header in that response.

so (by that MUST) the cache isn't allowed to propagate its
heuristically-chosen freshness lifetime to anyone else.

Since section 13.5.2 doesn't discuss Cache-Control, this looks
like a loophole in the spec (e.g., the cache could perhaps
add "Cache-control: max-age=1000000000") but I would hope that
proxy cache implementors aren't actively looking for loopholes
of this sort.

Probably, therefore, you should read the relevant part of 14.46
as if it said:

   113 Heuristic expiration
     MUST be included if the cache heuristically chose a freshness
     lifetime greater than 24 hours for a cache entry, the response
     is taken from that cache entry, and the age of the response is
     greater than 24 hours.

I can't see any reason to Warn anyone on a miss that creates
a new cache entry with a heuristic expiration lifetime, given
that the cache shouldn't be propagating these heuristic values
towards the client.

-Jeff

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 27 Sep 2002 22:19:51 -0600 (MDT)

Jeff,

	Thanks for a clarification! It looks like the answer depends on
whether "it is interesting" to add this Warning to a miss. That is, whether
there is any "use" in attaching such a Warning. You think it is not useful
because cache heuristics do not apply to misses. I think one could consider it
being useful because the Warning could be about upstream cache's heuristic,
not about the cache adding a Warning. See below.

> a new cache entry with a heuristic expiration lifetime

The only reason I can think of is the "garbage in, compliance out" principle:
the proxy should improve the "quality" of responses it forwards.  Imagine that
there is a non-HTTP/1.1 cache upstream that cached the response for more than
24 hours. Imagine that the requesting client agent supports Warnings but does
not analyze response age. If a compliant proxy adds a Warning (that the
upstream cache should have added, but did not!), the user will get a useful
Warning.

The above scenario is quite artificial, of course. I am not sure whether it is
good enough to say that the MUST in question should apply to misses.

Thank you,

Alex.