lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Why doesn't lynx cache HTML source?


From: Leonid Pauzner
Subject: Re: lynx-dev Why doesn't lynx cache HTML source?
Date: Fri, 13 Nov 1998 04:59:10 +0300 (MSK)

While BL made his attempt to analize 59 lynx-dev messages
for lynx internal cache pro at contra,
I spent few hours to analize HTTP 1.1 spec for caching rules.
<draft-ieft-http-v11-spec-rev-04>

I think my previous words for "1-document" cache are mistaken,
now I feel the picture as follows.


Lynx internal cache for HTML sources:
=====================================

1) Every document should be cached except local (which always available).
Use them for internal needs (*, [, \, etc) immediately without any checks,
the flag may be enabled in HTuncache_current_document().
(well, we store several latest documents only, because of space limitations...)

2) Let we have cached data (enough space, not delete entry yet),
   when use it for remote calls?
Do not use cache for any method other than http/https "GET"
Do not use cache if the origin document was incomplete (?)

Use cache - always validate cached data (see Note3):
use Last-Modified and ETag value from the previous request -
add If-Modified-Since: and If-None-Match: to GET request,
send protocol version as "HTTP/1.1"
If we got 304 (not Modified) status - use cached data,
but update header fields from this new responce.
If we got 200 (OK) status - do as usual but do not forget to pick it up
to the cache, with the flag for user interruption if any happen.
If we got other status - do as usual and NOTHING for cache in any case.


Note1: If we have only Last-Modified data and the origin server was HTTP1.0
we should have a possibility to avoid sending this string. (http-v11-spec)

Note2: We probably need sending "HTTP/1.1" for any request and any method
(to not confise the server ?), does we lost something from HTTP 1.1 client
features ourself?

Note3: According to http-v11-spec, the documents which became stale
because of expire, cache-control: no-cache, cache-control: max-age=...
should not be reloaded completely. Instead, they should be revalidated
with the remote server as we explain above.
There is an expiration model described in sections 13.2 and 14.9 of the docs
which allows sending documents without revalidation with the remote server
for documents that are not staled yet - we do not use it for now.
There may be also security considerations if we want a persistent cache.


Leonid.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]