Re: HTTP Caching Design

David W. Morris:
>
>
>
>On Sun, 7 Jan 1996, Koen Holtman wrote:
>
>> I think he can.  I believe you are interpreting the word `request' in
>> the wrong way.  History list browsing commands do not generate
>> requests in the HTTP sense.
>
>Well, at one recent point, a Netscape 2.beta on UNIX certainly did. 

Maybe I should have said `do not always cause the generation of
requests in the HTTP sense'.  See
http://www.amazon.com/expires-report.html for the complete details.

>I accept the notion that betas have bugs.  I haven't confirmed in the last
>few weeks that the problem still exists in the latest beta.

I don't know if this is a bug or designed functionality, all I can say
is that eralier versions of Netscape do not always generate requests.

>Since at present, the history list buffer is not the subject of any protocol
>specification, it would be hard to really argue about what it should do.

At present, the history list buffer _is_ a subject of a (draft)
protocol specification, see section 10.19 of the 1.1 draft.  I qoute:

 |  User agents often have history mechanisms, such as "Back" buttons 
 |  and history lists, which can be used to redisplay an entity 
 |  retrieved earlier in a session. By default, the Expires field does 
 |  not apply to history mechanisms. If the entity is still in storage, 
 |  a history mechanism should display it even if the entity has 
 |  expired, unless the user has specifically configured the agent to 
 |  refresh expired history documents.

The 1.0-04 draft has the same text.

The reason for this text is that anything else would cause a
performance penalty for content authors who go through the trouble of
using the Expires header in the right way.  Again, see
http://www.amazon.com/expires-report.html for a complete explanation,
and also see Roy's earlier post in this thread.

>Dave Morris

Koen.

Received on Monday, 8 January 1996 12:13:40 UTC