Re: [cp-patches] RFC: prevent URL degeneration - v2b

[Mark Wielaard]

Hi Chris,

On Mon, 2005-10-10 at 13:56 +0100, Chris Burdess wrote:
> >     if (authority.length() != 0 || file.startsWith("/"))
> >       {
> >         sb.append("//").append(authority);
> >       }
> 
> No (note that this is already what happens in 
> java.net.URLStreamHandler.toExternalForm

No it is not. Currently the authority is only added when it is
non-empty. What the above does is also add it when the file part starts
with a slash since in that case it really matters.

> , and it is wrong for most URL 
> schemes). Again, according to RFC 1738:
> 
>     A file URL takes the form:
> 
>         file://<host>/<path>
> 
>     where <host> is the fully qualified domain name of the system on
>     which the <path> is accessible, and <path> is a hierarchical
>     directory path of the form <directory>/<directory>/.../<name>.

Yes. But we are not looking for full RFC 1738 compliance. Although that
would be nice. We want to solve the bug that toExternalForm() produces
an String representation that does not create the same URL when given to
the constructor again. Also note that we are mainly talking about file
URLs here. And as previously shown the do not really follow the general
URL scheme "in the wild". In particularly the <host> part is often just
dropped.

> In java.net.URL, the file part is "/" + <path> here.

Not in our implementation. "/" is only added in front of the path if the
"free form" URL(String) constructor is used. Not when a URL is
constructed by given the individual parts. This might or might not be
deliberate/bug.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part