Conditional http get for dynamic pages
Scott Penrose
scottp at dd.com.au
Sun Nov 24 17:18:10 CST 2002
On Monday, Nov 25, 2002, at 06:19 Australia/Melbourne, David Dick wrote:
> Hmmmmm... Correct. My problem is probably a specific one. I'm
> building a inventory system (keep track of the amount of goods in a
> warehouse). This means that I can't use a cache for the volume of
> stock remaining type enquiries, cos it's vital that the application
> server is consulted for every enquiry. However, it's quite likely
> that the level of stock only changes relatively slowly.
>
> But if I take a MD5 Digest (for example) of the final page just before
> actually sending it and send it with the page as a ETag, the next time
> the user requests a "level of stock remaining" page (for example :)),
> if the page has the same MD5 Digest, I can just send a 304 and save
> the network traffic of a full response. Also extremely applicable to
> a "Search for a document" type pages, which i am using quite a lot.
Oh I see, yeah that sounds kind of exciting. The search idea is kind of
cool. I was thinking about the fact that a whole bunch of students in a
class room may all click on the same search string to Google. Of course
the silly proxy won't cache it because it is a CGI - however... in
theory it could cache it and use your example above. In that case
instead of an ETag it would just be the query that it caches against.
> But if you do take the hash before the gzip, you may not need to gzip.
> :) Of course, if you use a MD5 Digest after any possible compression,
> you can also use it for a Content-MD5 field :)
Umm... why not NEED to gzip ? What has the hash to do with compression.
Sure do the MD5 as you suggested above, bug compressions still reduces
bandwidth.
Scott
--
Scott Penrose
Open source developer
http://linux.dd.com.au/
scottp at dd.com.au
Dismaimer: Open sauce usually ends up never coming out (of the bottle).
More information about the Melbourne-pm
mailing list