#21 FilenameToUriString not handling Windows network paths correctly

[Adam Gross]

I'm running into an issue in uriparser 0.7.0 but I looked at the code for uriparser 0.8.0 and still believe that the issue exists. I am feeding the Windows function uriWindowsFilenameToUriStringA a path like "\<ip_address>\<directory>\app.exe". I would expect to receive "file://///<ip_address>/<directory>/app.exe" back from the function but instead am receiving "//<ip_address>/<directory>/app.exe".

I believe that this could be resolved by changing FilenameToUriString's calculation of the "absolute" variable from:

const UriBool absolute = (filename != NULL) && ((fromUnix && (filename[0] == _UT('/')))
|| (!fromUnix && (filename[0] != _UT('\0')) && (filename[1] == _UT(':'))));

to:

const UriBool absolute = (filename != NULL) && ((fromUnix && (filename[0] == _UT('/')))
|| (!fromUnix && (filename[0] != _UT('\0')) && (filename[1] == _UT(':')))
|| (!fromUnix && (filename[0] == _UT('\')) && (filename[1] == _UT('\'))));

That would essentially treat Windows paths that start with "\" to be absolute paths. Does that sound reasonable or is there something I'm missing about the intended behavior of this function?

[Adam Gross]

It appears that I didn't format my paths in the first paragraph correctly. I'll give this another try:

- I am feeding the Windows function uriWindowsFilenameToUriStringA a path like "\\<ip_address>\<directory>\app.exe".
- I would expect to receive "file://///<ip_address>/<directory>/app.exe" back from the function.
- Instead I am receiving "//<ip_address>/<directory>/app.exe" back.

[Adam Gross]

It looks like the URI spec says that this could be:

file://<ip_address>/<directory>/app.exe

But you would have to change uriparser's URI-to-file parsing functionality to accept that as well. I don't believe that it correct decodes it to:

\\<ip_addrses>\<directory>\app.exe

[Sebastian Pipping]

Hello! Function uriFilenameToUriString was not made to handle Windows share paths initially. I don't oppose to make the suggested changes.
I cannot test myself on Windows. Can you confirm that "file://///<ip_address>/<directory>/app.exe" with "file://///" really is working as expected on Windows, e.g. Internet Explorer accepts it and doesn't correct it to something that it considers to be more right?
Ideally, I would also like a link to some official specs where that style of URI is defined to be right with URIs to Samba shares.
And I wonder if the opposite direction (uriUriStringToFilename) should support those shares then, too.

PS: I tried to reach you by mail at grossag@sf... but I got back an error. Please check your SF.net mail setup. Thanks!

[Adam Gross]

Thanks for the response. I'm not sure how to set up the sf.net mail but you can reach me at gmail using that same username.

I did some more research and found that it would be safer for you to change it to:

file://<ip_address>/<directory>/app.exe

This appears to be the documented way of accessing network shares using the file URI schema as described in https://en.wikipedia.org/wiki/File_URI_scheme

[Dmitry Repkin]

I confirm the problem exist and the way shown by Adam is correct. I found the solution independently, my own patch is attached.

This issue does not allow bmx project (which uses uriparser) to access network drives under Windows.

[Sebastian Pipping]

Should be fixed now, both conversion back and forth.
If not, please don't hesitate to re-open.
Expect a release of 0.8.2 in a few minutes.