Hi Alvaro, thanks for looking into this. It seems that the problematic behaviour I'm describing is due to 'pathinfo' support :)
So, in your second example; "curl http://localhost:9999/1/2/test/this/is/pathinfo";, results in 'This a test'. Why doesn't cherokee send a 404 in this case? Is this standard behaviour? I'm not sure if bzr is relying on undefined behaviour here I do know that this works with apache and lighttpd. When branching via http, bzr looks for ''http://example.com/repo/.bzr/checkout/format'. If the 'checkout' directory does not exist (i.e. bzr gets a 404), bzr should not fail it just behaves slightly differently. With cherokee, if the 'checkout' directory does not exist, it serves 'http://example.com/repo/.bzr/' instead of sending a 404, and this breaks bzr. I hope I've been a little clearer this time:) Eoin On 10/30/07, Alvaro Lopez Ortega <[EMAIL PROTECTED]> wrote: > Eoin Hennessy wrote, On 25/10/2007 09:26: > > > The cherokee bug tracker [0] seems to be misbehaving, so in it's > > absence: > > We had so many problem with the spammers that I had to take it down > "temporarily". A few days latter we discussed whether it was worth > spending time on maintaining our infrastructure or if was more > convenient for us to simply outsource it somewhere and relay all that > messy stuff on them. > > I suppose that it is time to redirect the old BTS to the one that we > created on Google code. It was not more than a test, but it has worked > fairly well so far: http://code.google.com/p/cherokee > > > I recently looked at serving bazaar-ng branches via http with cherokee > > (using the 'common' handler). I noticed that cloning any branches via > > http was failing. When branching via http, bzr bases its behaviour on > > the presence of certain files in it's control directory (e.g. > > .bzr/checkout/format). It seems that cherokee doesn't send a 404 in > > the absence of these files, redirecting instead to the root directory, > > breaking bzr. > > > > I've verfied this behaviour is present in 0.5.6 and trunk. I've > > attached a small patch (against trunk) for common_handler.c that just > > emits a 'http_not_found' error code instead of redirecting when a > > file/dir is absent. This allows bzr to operate as expected. > > There is something I don't quite understand. Check this out: > > ========== > $ cat >/tmp/common.conf <<FIN > server!port = 9999 > vserver!default!document_root = /tmp > vserver!default!directory!/!handler = common > FIN > > $ mkdir -p /tmp/1/2/3 > $ ./cherokee -C /tmp/common.conf & > > $ curl http://localhost:9999/1/2/no -D - > HTTP/1.1 404 Not Found > Connection: close > Date: Tue, 30 Oct 2007 00:03:28 GMT-4 > Server: Cherokee/0.6.0b933 (UNIX) > Content-Type: text/html > Content-Length: 260 > Cache-Control: no-cache > Pragma: no-cache > P3P: CP=3DNOI NID CURa OUR NOR UNI > ========== > > In fact, it does also handle requests with pathinfo: > > ========== > $ echo "This a test" > /tmp/1/2/test > > $ curl http://localhost:9999/1/2/test > This a test > > $ curl http://localhost:9999/1/2/test/this/is/pathinfo > This a test > > $ curl http://localhost:9999/1/2/test.no -D - | grep HTTP > HTTP/1.1 404 Not Found > ========== > > > Perhaps redirection behaviour like this should be left to the user > > to configure? > > Everything seems to be working fine on my side. As far as I have seen, > your patch would break the pathinfo support. Actually, I could not > reproduce the problem that you described so I might have taken it > wrong. Could you please clarify it? > > Thanks Eoin!! :-) > > -- > Greetings, alo. > http://www.alobbs.com > > _______________________________________________ Cherokee mailing list [email protected] http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee
