unexpected cache issue when http errors

unexpected cache issue when http errors

[nicolas.dely]

Hi,

I would like to share an unexpected cache behaviour with this list and 
discuss about a solution.

Indeed we are using cgit to provide a web interface to our internal user 
and also to provide file to our reviewboard server.

We are experiencing some cache issue on static pages when data are not 
pushed yet to server but reviewboard tries to access these 
files/repositories. Cache is adding even 404, 401 or 500 error for 
static page, we can workaround this issue after reducing/setting static 
cache issue but it looks not very useful to cache http errors.

Do you think it is possible to only cache when HTTP is 200 OK? Other ideas?

PS: I've seen a cache issue (lock file) but nothing about http errors

Regards

Nicolas

unexpected cache issue when http errors

[john]

On Mon, Mar 30, 2015 at 07:15:27PM +0200, Nicolas Dely wrote:
> I would like to share an unexpected cache behaviour with this list and 
> discuss about a solution.
> 
> Indeed we are using cgit to provide a web interface to our internal user 
> and also to provide file to our reviewboard server.
> 
> We are experiencing some cache issue on static pages when data are not 
> pushed yet to server but reviewboard tries to access these 
> files/repositories. Cache is adding even 404, 401 or 500 error for 
> static page, we can workaround this issue after reducing/setting static 
> cache issue but it looks not very useful to cache http errors.
> 
> Do you think it is possible to only cache when HTTP is 200 OK? Other ideas?

I don't think it will be easy to change the behaviour to cache only on
200 responses, and I'm not sure it's desirable to do so since the
process of determining that a result is an error may involve significant
work (e.g. loading packed refs or pack indexes).

I can see an argument for changing the default for "cache-static-ttl" to
a positive value, so that if we do cache an error result it will
eventually time out without needing another page to be written into that
cache slot, but I'm not sure I understand how you reviewboard server can
access files that have not yet been pushed to the Git server.  If you're
reviewing committed changes, shouldn't the review be posted by a hook on
the server, which would ensure that the commits are available before
reviewboard knows about them?

unexpected cache issue when http errors

[nicolas.dely]

Hi John,

On 03/31/2015 08:39 PM, John Keeping wrote:
> On Mon, Mar 30, 2015 at 07:15:27PM +0200, Nicolas Dely wrote:
>> Do you think it is possible to only cache when HTTP is 200 OK? Other ideas?
> I don't think it will be easy to change the behaviour to cache only on
> 200 responses, and I'm not sure it's desirable to do so since the
> process of determining that a result is an error may involve significant
> work (e.g. loading packed refs or pack indexes).
thank you for quick answer and feedback about amount of work required to 
cache only 200 responses ;-)

> I can see an argument for changing the default for "cache-static-ttl" to
> a positive value, so that if we do cache an error result it will
> eventually time out without needing another page to be written into that
> cache slot, but I'm not sure I understand how you reviewboard server can
> access files that have not yet been pushed to the Git server.  If you're
> reviewing committed changes, shouldn't the review be posted by a hook on
> the server, which would ensure that the commits are available before
> reviewboard knows about them?
Regarding reviewboard, the tool works in a client/server architecture.
reviewboard client (rbtools) is supposed to send to reviewboard server 
local git patch/diff including full index of prev and new version. 
Server is looking for blobs belonging to prev version and apply patch 
chunks to them. Ie only blobs belonging to prev/origin version are 
required and must be pushed on git server to apply diff on them => pre 
commit reviews.

issues happen when:

  * new git repo: people do review request before pushing initial
    version => cache "no repository found"
  * missing intermediary version: people is updating or creating a
    review request an forget to push the prev version before submitting
    diff => cache "file not found"
  * reviewboard server is not allowed by gitolite (*) to read this new
    repo => cache "permission denied"

(*) we have implemented several apache-perl modules so that cgit check 
user permission according to gitolite access ie ldap username 
authenticated as same permission as username.pub key

Nicolas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20150401/0a879368/attachment.html>