Subject: Re: bug#76982: 30.1; url-generic-parse-url cannot parse Windows file paths

From: Eli Zaretskii <[email-masked]>
Date: Sun, 13 Apr 2025 12:16:19 +0300

> Date: Tue, 08 Apr 2025 18:13:57 -0400
> From: Sebastián Monía <[email-masked]>
> Cc: [email-masked], [email-masked]
> 
> On Mon, Apr 7, 2025, at 11:48 AM, Sebastián Monía wrote:
> > Eli Zaretskii <[email-masked]> writes:
> > > It can have other components in file:// URIs?  If so, can you show an
> > > example?
> > 
> > The URIs can have an "authority" segment, an example from
> > https://www.rfc-editor.org/rfc/rfc8089.html#appendix-B
> > 
> > "file://host.example.com/path/to/file"
> > 
> > And also I just noticed that "localhost" is valid for authority, so I
> > should add a test like this:
> > 
> > (should (equal (url-filename (url-generic-parse-url "file://localhost/c:/path/to/file")) "c:/path/to/file"))
> 
> Added this test.
> 
> > > The problem with your proposal is that the value of 'file' is
> > > incorrect between where it is first set and where you correct it.  Any
> > > code added later that uses 'file' in-between might cause bugs if the
> > > person who adds such code is not aware of this subtlety.  By contrast,
> > > under my suggestion 'file' has the correct value from the get-go.
> > 
> > You are right :) I hadn't considered this. Will revisit the code and see
> > how I can handle things earlier.
> 
> Now the leading / is stripped much closer to where the 'file' variable 
> assignment takes place, and also after the hostname/authority portion. 
> 
> Let me know what you think!
> Seb

Thanks, I installed this on master.  However, I needed to fix one of
the tests, because it failed for me.  Please see my followup changes,
and if you think I fixed the test incorrectly, let's discuss.

For now, I'm closing this bug.