List Info

Thread: Re: Serving a bzr repository via http




Re: Serving a bzr repository via http
country flaguser name
Spain
2007-11-02 17:45:26
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://e
xample.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 <alvarognu.org> 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:99
99/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
 > Cherokeecherokee-project.com
 > http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee
 >


-- 
Greetings, alo.
http://www.alobbs.com
_______________________________________________
Cherokee mailing list
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

[1]

about | contact  Other archives ( Real Estate discussion Medical topics )