Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
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
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.
curl 7.57.0 and up interpret this according to Appendix E.3.2 of RFC 8089 but then returns an error saying this is unimplemented. This is actually a regression in behavior on both Windows and Unix. Before curl 7.57.0 this URL was treated as a path of "//foo/bar" and then passed to the relevant OS API. This means that the behavior of this case is actually OS dependent. The Unix path resolution rules say that the OS must handle swallowing the extra "/" and so this path is the same as "/foo/bar" The Windows path resolution rules say that this is a UNC path and automatically handles the SMB access for the program. So curl on Windows was already doing Appendix E.3.2 without any special code in curl.