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