Serving a bzr repository via http

Hello all,

The cherokee bug tracker [0] seems to be misbehaving, so in
it's absence:

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.

Perhaps redirection behaviour like this should be left to
the user to configure?

Thanks,
Eoin

[0] http://www.cher
okee-project.com/bugs/

_______________________________________________
Cherokee mailing list
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

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

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://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

Thanks Alvaro, this fixes the issue nicely!

Eoin


On 11/2/07, Alvaro Lopez Ortega <alvarognu.org> 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://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