unexpected cache issue when http errors
Nicolas Dely
nicolas.dely at technicolor.com
Wed Apr 1 16:25:43 CEST 2015
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>
More information about the CGit
mailing list