transports refuse file:/something URIs, which rfc2396 state are valid

[James Westby]

Hi,

If you pass a file:/something URI to get_transport bzrlib will
refuse to use it, saying it should be file:///something or file://localhost/something.

However, a strict reading of rfc 2396 says that it is valid:

absoluteURI = scheme ":" ( hier_part | opaque_part )
hier_part = ( net_path | abs_path ) [ "?" query ]
net_path = "//" authority [ abs_path ]
abs_path = "/" path_segments
path_segments = segment *( "/" segment )

so file:/something is absoluteURI -> hier_part -> abs_path.

This is tripping me up right now as apt is perfectly happy with these
URIs, but bzrlib isn't, so I'm having to do some mangling.

Thanks,

James

[Robert Collins (lifeless)]

Is apt happy with the more regularly known uris? You may be strictly
right, but if you check the wiki on file uris you'll see its not what
browsers etc expect.

[James Westby (james-w)]

On Wed, 01 Sep 2010 21:34:19 -0000, Robert Collins <email address hidden> wrote:
> Is apt happy with the more regularly known uris? You may be strictly
> right, but if you check the wiki on file uris you'll see its not what
> browsers etc expect.

Yes, apt is happy with either form.

chromium rewrites file:/something for me to be the more usual file:///.

The reason I reported this bug is that I want to take uris reported by
python-apt and fetch them using bzrlib (mainly because apt writes
allsorts of output if I use it directly), to do that I currently have to
rewrite the (apparently valid) uris myself in between.

Thanks,

James

[James Westby (james-w)]

On Wed, 01 Sep 2010 18:10:59 -0400, James Westby <email address hidden> wrote:
> The reason I reported this bug is that I want to take uris reported by
> python-apt and fetch them using bzrlib (mainly because apt writes
> allsorts of output if I use it directly), to do that I currently have to
> rewrite the (apparently valid) uris myself in between.

This is no longer an issue for me, as I am now using apt to do the
download, which is the right thing to do here anyway, but this may
warrant a bzr change anyway.

Thanks,

James

[Martin Pool (mbp)]

I think the grammar there says that urls in general don't need a host
part; that's not necessarily convincing that file urls don't need one.

According to <http://en.wikipedia.org/wiki/File_URI_scheme> it is
needed. (wp is hardly authoritative but perhaps it's an accurate
summary of the rfc.)

All that said if apt accepts them we might as well, though we
shouldn't generate them.

[Martin Pool (mbp)]

<http://tools.ietf.org/html/rfc1738#section-3.10> says they must have
a host part; and rfc2396 doesn't amend this afaics. But let's be
liberal in what we accept.