cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: Last-Modified and If-Modified-Since on pipelines
Date Tue, 22 Apr 2003 09:24:47 GMT
Miles Elam wrote:
>> Cool work, Miles! This would be one step further towards real 
>> proxy-friendliness of Cocoon: once Etag support is there we would be 
>> really close to proxy nirvana (not only for people behind a proxy but 
>> also for Cocoon used with an http accelerator in front of it). Could 
>> you please submit your patch to Bugzilla so that it doesn't get lost? 
>> I plan to review and commit it shortly (and will possibly need your 
>> help in testing and documenting it), but have no CVS access ATM. 
> Thanks.  With regard to bugzilla, there's another bug there regarding 
> Last-Modified headers (bug 7952) but it's targeted toward 2.0x and 
> appears a bit stale.  I'll create a new bug and folks can 
> redirect/reference as they wish I guess.  The new bug is 19206.

OK, thanks. Can you however post the patch in unified diff format (diff 
-u)? There might be something wrong with your patch, I'm choking on it.

Some quick comments, however:

1. relation with Expires configuration should be taken into account. 
This means that if the Expires Object (available in CachedResponse) is 
still fresh, a 304 should be sent right away. Am I right?

2. this code:

              // Allow for 304 (not modified) responses in dynamic content
              if (super.checkLastModified( environment, 
this.cachedLastModified )) {
                  return true;

could be easily rewritten as
              return super.checkLastModified(environment, 

do you agree?

> I have some preliminary ETag code but I'm stuck on a particular issue: 
> what to hash on.  Is there a ready-to-use routine for computing a hash 
> code from a byte array?  I was originally going to do it off of 
> timestamp and then the Object.hashCode() of the CachedValue entry.  This 
> doesn't really buy much more than Last-Modified though: it's only an int 
> and is tied to the cache object rather than the value held by the cache 
> object.  The only thing that really makes sense to me is actually 
> working off the byte array.  But then constructing the CachedValue 
> object will take longer and be more expensive.  Thoughts?  Does it 
> really matter for a first implementation or should I just go ahead with 
> hashCode()?

I think that the Etag shouldn't be an hashCode, since it's not 
reversible. The idea of Etag is that it should be possible to lookup the 
cache with the Etag value and return the resource identified by the Etag 
itself. I was thinking about using the cache key, though this might well 
open a security hole since it's an information that I'm not sure it's 
good to give away.


Gianugo Rabellino
Pro-netics s.r.l.

View raw message