Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <46290D38.8050901@apache.org>
Date: Fri, 20 Apr 2007 20:58:00 +0200
From: Grzegorz Kossakowski <gkossakowski@apache.org>
User-Agent: Thunderbird 1.5.0.10 (X11/20060911)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Broken caching of servlet: source in some cases
References: <20070419132805.E1FD41A9838@eris.apache.org>
 <4627708D.6080104@apache.org> <46277664.2030200@apache.org>
 <f0a72i$inj$1@sea.gmane.org> <4628A094.9080001@apache.org>
 <f0aebk$3ct$1@sea.gmane.org> <4628C4A7.9020102@apache.org>
 <f0an9q$ttp$1@sea.gmane.org> <4628F8A9.5060704@apache.org>
 <f0b0p2$7ts$1@sea.gmane.org>
In-Reply-To: <f0b0p2$7ts$1@sea.gmane.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Alexander Klimetschek napisał(a):
> Grzegorz Kossakowski schrieb:
>> Why not earlier? This way I'd be able to help with this issues. Now it
>> is not possible because I cannot reproduce most of your problems.
> 
> Sorry, I understand, but it's kinda difficult to strip down those
> sitemaps and set them up in a new context like the servlet-service-samples.

Maybe try creating sample from scratch instead of stripping down your complicated pipelines? I guess this would help also you to track down
cases when it actually fails and focus on it.

>>> 1) Last-Modified header set to -1 instead of skipping it (my last mail)
>>
>> Couldn't reproduce. I also think that this should not harm even though
>> it's not valid to set Last-Modified header to -1. What kind of
>> problem this behavior causes for you?
> 
> As described in my last mails: having a last-modified of -1 and
> comparing it with a if-modified-since of -1 (aka both are unknown, no
> caching should be tried at all) you get a not-modified result because of
> the following line in HttpEnvironment.isResponseModified():
> 
>             return (if_modified_since / 1000 < lastModified  / 1000);
> 
> which results in -1/1000 == -1/1000 => response is *not* modified. This
> is wrong, since two -1 values mean that there is nothing known about
> modification timestamps, so it should retrieve the full content.

I see. The only place where if-modified-since could be set to -1 and that I know of is ServletSource$ServletValidity#isValid() method...
You got me! (I realized what's going on with this one while writing an e-mail)
The bug is in ServletSourc#getValidity(). It returns validity object even though information (Last-Modified header) needed to calculate it
does not exists! This way, ServletValidity will hold "-1" value in it's lastModified field and will pass it to the request as
If-Modified-Since next time it is asked if it is still valid.
This bug only show up if called pipeline is non-caching and calling is caching one.
I'm really not sure why I didn't catch it while implementing caching for ServletSource.

I'll commit fix in minutes, could you test it in your env?


> I fixed it by introducing servlet:<bean-name>:/foo/bar globally unique
> URLs, at least when a local servlet call is made (ie. servlet:/foo/bar).
> servlet:super:/ and servlet:something:/ stay unmodified (maybe these
> have to be tweaked as well to solve my last unresolved exception).

Think about servlet:<shorthand_name>:/** URIs as _relative_ ones (because they are relative to block's context) and servlet:<bean-id>:/** as
_absolute_ ones (because they are independent from any context). Now, ServletSource#getURI() *must always* return absolute one because it's
part of contract.
So if you have it implemented, can you provide a patch?

> No, you don't necessarily see the exception, in the end you get an empty
> response and this gives a new exception, the well-known "Premature end
> of file". Any exception in the called block must be passed through,
> otherwise you never see what you were doing wrong in your "backend"
> sitemap. Had a lot of problems with that when exceptions were swallowed
> in the first blocks-fw implementation.

I don't agree with this one. AFAIK, in servlet-service-fw implementation exception are passed back to the calling sitemap. It was you who
provided a patch: https://issues.apache.org/jira/browse/COCOON-1954 :-)

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/