unexpected cache issue when http errors

[nicolas.dely at technicolor.com (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>