Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Restore old behavior for file:////foo/bar URLs #2438
This is a fairly common thing to end up in scripts via constructions that do
curl allowed this prior to 7.57.0 but it was broken by adding "support"
Given the fact that curl does not actually implement support for UNC paths I think it would be better to restore the old behavior.
This may be a case where the correct behavior of curl on Unix and the correct behavior of curl on Windows are not actually the same thing. Firefox and Chrome handle this case differently on different operating systems. Both of them treat it as a local filesystem path on Unix and a UNC path on Windows.
Although its not clear to me if this behavioral difference in Firefox and Chrome is something they explicitly implemented or if it is really just a difference in how Linux and Windows treat paths like
You're right. The old windows behavior appears to be passing it as
So actually there is a Windows regression here too right now. Before version 7.57.0, curl already handled UNC paths like
And that also means my change to test2072 will fail on windows. Is there a way to make a test OS specific?
You're right, just like above it should just be passed to the OS as
Windows file shares?
I think Appendix E.2.3 of RFC 8089 is really just explaining how Windows path resolution combines with
changed the title from
Allow file:////path/to/file URLs again
[WIP] Restore old behavior for file:////foo/bar URLs
Mar 30, 2018
I didn't see a way to flag tests as OS specific so I threw 2072 in the disabled list with a note saying it was OS specific behavior and that the test was for the Unix behavior.
I don't have a Windows box set up to be able to build stuff like this. With this patch it should behave like it did before the changes in 7.57.0 and trigger SMB access on Windows again.
I wanted it to be part of the specification. However updating such an ancient and underspecified scheme was already contentious enough, without making any outright changes -- so we're left with this gap. The informational appendix was my attempt at describing what seemed like the best chance for interoperability without actually writing any normative language; but that lack of normativity also meant it received less scrutiny (so more grains of salt are required along with it.)
If/when IETF regains the energy and appetite for it, I'm confident a future version of the
In terms of this particular PR, is this a correct summary of what gets passed to the OS to open()?
If so, it's fine with me. (I derived those bottom rows by reading the code. If that's how it actually works, then...
On Thu, Mar 29, 2018 at 10:23:12PM -0700, Jon DeVree wrote: And that also means my change to test2072 will fail on windows. Is there a way to make a test OS specific?
You can use an appropriate <precheck>. There aren't any existing ones for OS detection, but perl is available so I'm sure there's a one-liner that would do it.
Sorry, it was getting late and I didn't actually phrase that well. I meant to say that it was probably only intended to be implemented on platforms that already use Windows/UNC path resolution behavior.
I don't know if that actually matches your intentions, but its what I intended to say.
So curl on Windows should follow Appendix E.2.3 because that is how Windos path resolution works. Whereas curl on Unix should just follow Unix path resolution behavior instead. This OS dependent behavior is how Mozilla and Chrome appear to behave.
Yes. In fact I hadn't thought to try the ones with the explicit localhost, but that is how they behave.