LocalTransport has readonly+ in the file path
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
loggerhead |
Triaged
|
Critical
|
Unassigned |
Bug Description
I was getting 404 no matter what I did so I started investigating and this is what I found so far:
Traceback (most recent call last):
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
self.handle()
File "/usr/lib/
BaseHTTPReq
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
return self.applicatio
File "/usr/lib/
return self.applicatio
File "/usr/lib/
return self.applicatio
File "/usr/lib/
return self.app(environ, start_response)
File "/usr/lib/
transport, self)(environ, start_response)
File "/usr/lib/
assert False, self.transport
AssertionError: <bzrlib.
Is it normal that readonly+ is in the file path? Could it be a middleware that is not working?
/etc/serve-
served_
port=8090
prefix=/
loggerhead 1.19~bzr479-2
python-paste 1.7.5.1-4.1ubuntu1
python-pastedeploy 1.5.0-3
python-pastescript 1.7.5-2
Ask me if you need more info.
Changed in loggerhead: | |
status: | New → Triaged |
importance: | Undecided → Critical |
summary: |
- LocalTransport have readonly+ in the file path + LocalTransport has readonly+ in the file path |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
...
AssertionError: <bzrlib. transport. local.LocalTran sport ///var/ lib/loggerhead/ trunk-rich/ readonly% 2B./>
url=file:
>
> Is it normal that readonly+ is in the file path? Could it be a
> middleware that is not working?
Do you know where the '.' is coming from? It is, actually, expected to file:// /...".
have readonly+, but only at the beginning. So: "readonly+
The issue is that somehow we are getting a simple relative path "."
rather than the expected URL file:///...
readonly+file:/// is our way to make sure to disallow write actions on
paths.
Offhand 'serve-branches' isn't a very maintained way of service
Loggerhead. (bzr serve --http IIRC is the recommended way.)
So there is probably a bug in here, but I'm not sure whether it is
that we aren't canonicalizing some input from the user, or whether it
is a configuration thing.
John www.enigmail. net/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Cygwin)
Comment: Using GnuPG with undefined - http://
iEYEARECAAYFAlD uXpMACgkQJdeBCY SNAAP5HwCfYCECh lNdxBD0Fzi/ BC9gfaen 3Q8svJRILGibegN n7
4v4AnR0jCrBPyJw
=QWyp
-----END PGP SIGNATURE-----