Thanks Alvaro, this fixes the issue nicely! Eoin
On 11/2/07, Alvaro Lopez Ortega <[EMAIL PROTECTED]> wrote: > Eoin Hennessy wrote, On 30/10/2007 18:30: > > Hi Alvaro, thanks for looking into this. > > I have just committed r945. It adds a new handler_common configuration > parameter "allow_pathinfo" with which you can make the common handler > to stop parsing the pathinfo string. > > It ought to be enough to make it work with bzr (using the common > handler). There are also a couple QA tests to ensure it works as > expected. > > I hope it fixes your problem. > Cheers! > > > 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 > > > > > -- > Greetings, alo. > http://www.alobbs.com > _______________________________________________ Cherokee mailing list [email protected] http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee
