Windows file prefix
mlambley opened this issue · comments
I know that there's been multiple discussions in multiple places about this. But please bear with me.
The following refers to a valid path and file on my Windows 10 machine:
<?php
include './vendor/autoload.php';
use Sabre\Uri;
$basePath = 'file:///C:/Repos/my-path/tests/';
$newPath = 'my-file.json';
var_dump(Uri\resolve($basePath, $newPath));
//Outputs "file://C:/Repos/my-path/tests/my-file.json"
Which fails because it replaced file:/// with file:// and the C: is therefore treated as host:port
Could you please either let me know what I'm doing wrong, or if it is a bug, let me know and I'll organise a PR for you.
Thank you.
It looks like this is a bug in the PHP function parse_url
. It works correctly in _parse_fallback
but since parse_url
succeeds _parse_fallback
is never called.
>>> parse_url('file:///C:/Repos/my-path/tests/')
=> [
"scheme" => "file",
"path" => "C:/Repos/my-path/tests/",
]
>>> Sabre\Uri\_parse_fallback('file:///C:/Repos/my-path/tests/')
=> [
"scheme" => "file",
"host" => "",
"port" => null,
"user" => null,
"path" => "/C:/Repos/my-path/tests/",
"fragment" => null,
"query" => null,
]
I somehow remember someone reporting this issue in the past. did you search thru the bugtracker?
I found a number of bugs with people passing in file:// which would make sense that it fails, but none where people are explicitly passing in file:///
I notice a reference to peter postman in another issue. Perhaps that can help. Let me look into this further.
Confirmed. PHP's parse_url kinda sucks.
This will be fixed by #25
Sorry I checked issues but didn't check PRs.
Once that is merged this ticket can be closed.
At best you woud also file a php bug