As this package is called sabre/uri, and not sabre/url, I expected it to handle any valid URI. For example, it should handle any URI scheme. However, that is not the case, because it uses parse_url internally. The docs clearly say that

This function is intended specifically for the purpose of parsing URLs and not URIs. However, to comply with PHP's backwards compatibility requirements it makes an exception for the file:// scheme where triple slashes (file:///...) are allowed. For any other scheme this is invalid.

http:// and file:// work, any other URI results in an Errror: Unsupported operand types.

Examples:

Uri\parse('ftp:///whatever')
Uri\parse('ssh://[email protected]/fruux/sabre-uri.git')

This really limits the usefulness of this function.

Relating to this issue: https://github.com/owncloud/core/issues/23740

Tested on php 7.0.4 on Ubuntu 16.04.

The parse function in lib/functions.php has trouble with colon characters in the wrong place in the uri. The parse function in turn uses php's parse_url function which is what is failing under certain (odd) circumstances.

If there is a colon character as the second to last character in a uri phps parse_url function fails to parse the uri. When phps parse_url function fails and returns false, sabres parse function also fails. It's also worth noting that phps parse_url works if you move the colon anywhere else in the string.

Here's how this can be reproduced:

<?php print "Works:\n"; var_dump(parse_url('/webdav/test3')); print "\nFails:\n"; var_dump(parse_url('/webdav/test:3')); ?>

I'm not sure how or where this is most appropriate to fix.

Thanks

_parse_fallback(), together with functions that directly or indirectly call it, are missing @throws in their respective docblocks.

This is annoying for static analysis, for example PHPStorm tells me:

This PR adds @throws where appropriate.

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.

If I increase phpstan level to 9, then it detects that function parse(string $uri): array can return array<string, int|string|null> and that is correct.

Key "port" is an int value. Other keys have a string value. "Unused" keys have value null.

If I actually document:

 * @return array<string, int|string|null>

Then phpstan complains about:

------ ------------------------------------------------------------------------------------------------- 
  Line   lib/functions.php                                                                                
 ------ ------------------------------------------------------------------------------------------------- 
  60     Parameter #1 $string of function substr expects string, int|string|null given.                   
  68     Parameter #2 $str of function explode expects string, int<min, -1>|int<1, max>|string given.     
  117    Parameter #1 $str of function ltrim expects string, int<min, -1>|int<1, max>|string given.       
  138    Parameter #1 $str of function strtolower expects string, int<min, -1>|int<1, max>|string given.  
  161    Parameter #1 $str of function strtolower expects string, int<min, -1>|int<1, max>|string given.  
 ------ ------------------------------------------------------------------------------------------------- 

because it has not been told the detail that: Key "port" can have value int|null All other keys have value string|null

If there is some way to express this in PHPdoc, then that would be good - because the line numbers above are processing keys that do not have int value.

For now, I set the type of the keys to mixed - at least that recognizes that the values are definitely not all string.

This is a rebase of PR #25 with conflicts resolved...

In the 2nd commit, I have added some comments and simplified the windows_path regex in a similar way to what @peterpostmann has suggested in comment https://github.com/sabre-io/uri/pull/25#discussion_r946370109

Hello!

I'm using league/json-reference library for json validation, and this library uses sabre/uri for resolving external references in json-schema.

Everything works fine on Linux machines, but not on Windows. For example if function Sabre\Uri\resolve being called with parameters

$basePath = 'file://D:/development/projects/markirovka/storage/app/jsonSchemas/undefined_order.json';
$newPath = './types/turnover_type.json';

result will be

file://D/development/projects/markirovka/storage/app/jsonSchemas/types/turnover_type.json

The comma after disk partition letter will be missed, and it couse an error.

I've being debugging a bit, and I think it can be fixed with minor changes in lib/functions. Function for Windows detection:

/**
 * This function returns true if aplication run in Windows environment
 * @return bool
 */
function isWindows() {
    return strtoupper(substr(PHP_OS, 0, 3)) === 'WIN';
}

And changes in build function:

function build(array $parts) {

    $uri = '';

    $authority = '';
    if (!empty($parts['host'])) {
        $authority = $parts['host'];
        if (!empty($parts['user'])) {
            $authority = $parts['user'] . '@' . $authority;
        }
        if (!empty($parts['port'])) {
            $authority = $authority . ':' . $parts['port'];
        }
    }
// ============= add this ===============
    /**
     * on Windows systems for local URIs $parts['host'] will be a partition letter,
     * and we must add colon after it
     */
    if (isWindows() && !empty($parts['scheme']) && $parts['scheme'] == 'file') {
        $authority .= ':';
    }
// ==================================

    if (!empty($parts['scheme'])) {
        // If there's a scheme, there's also a host.
        $uri = $parts['scheme'] . ':';

    }
    if ($authority || (!empty($parts['scheme']) && $parts['scheme'] === 'file')) {
        // No scheme, but there is a host.
        $uri .= '//' . $authority;

    }

    if (!empty($parts['path'])) {
        $uri .= $parts['path'];
    }
    if (!empty($parts['query'])) {
        $uri .= '?' . $parts['query'];
    }
    if (!empty($parts['fragment'])) {
        $uri .= '#' . $parts['fragment'];
    }

    return $uri;
}

What do you think about this suggestion?

And excuse my english, it's not my native language.

Hi,

I think a found a bug on windows. For the uri 'file:///C:/path/file_a.ext' parse returns

array (size=2)
  'scheme' => string 'file' (length=4)
  'path' => string 'C:/path/file_a.ext' (length=18)

This causes resolve('file:///C:/path/file_a.ext', 'file_b.ext') to generate wrong URIs: file://C:/path/file_b.ext (one slash is missing, because the empty host is missing).

parse_url produces the same result, which is correct with reagards to http://php.net/manual/en/wrappers.file.php, but it cannot be used to reconstruct file uris directly.

The behavior of _parse_fallback is correct and has this output:

array (size=3)
  'scheme' => string 'file' (length=4)
  'path' => string '/C:/path/file_a.ext' (length=19)
  'host' => string '' (length=0)

parse should also produce this output.

Note: I had to remove the white spaces before and after the regex because I couldn't get it tested otherwise (using PHP 7.1)

1. add an explicit unit test for issue #31
2. Adjust README to mention Windows-style paths
3. Add empty host and leading slash to Windows file paths (this is a remake of PR #71
4. changelog and version bump to 3.0.0

While using sabre/uri in a work project, I noticed an inconsistency. It looks almost like the author forgot about the "pass" field:

1. parse() does not include "pass" with null value if no password is found in the URI,
2. build() does not include "pass" in the string URI even when it's passed in the input data.

Whenever a URL contains no host part, the presence of a colon will make PHP's parse_url fail. To workaround this bug, we need to encode the colon in this situation.

However we do not encode colons for full URLs.

Fixes https://github.com/fruux/sabre-uri/issues/9

@evert would you accept a backport for this to the sabre-uri 1.0 series ? (not sure how to proceed, no stable branches ?)

Please review

I did a minor upgrade on https://github.com/zobo/php-language-server and and after spending hours on debugging why a whole lot of things stopped working realized that Release 2.2.3 with #71 changed how Windows file URIs are parsed.

Now instead of getting path: C:/dir/... we get path: /C:/dir/....

I have looked into a few different issues here to figure out why this would be OK, but I'm sorry, this is a breaking change and should have been released under a new major version.

Something not mentioned in the official documentation:

https://sabre.io/uri/usage/

but only in the source code:

https://github.com/sabre-io/uri/blob/master/lib/functions.php

is this piece:

// Normally a URI must be ASCII, however. However, often it's not and
// parse_url might corrupt these strings.
//
// For that reason we take any non-ascii characters from the uri and
// uriencode them first.
$uri = preg_replace_callback(
    '/[^[:ascii:]]/u',
    function ($matches) {
        return rawurlencode($matches[0]);
    },
    $uri
);

Urlencoding is NOT appropriate for domain name / FQDN!

For example, these IRIs:

• https://пример.рф/
• https://приклад.укр/
• https://παράδειγμα.ελ/

should NOT be parsed to:

array (size=7)
  'scheme' => string 'https' (length=5)
  'host' => string '%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D1%80.%D1%80%D1%84' (length=49)
  'path' => string '/' (length=1)
  ...

array (size=7)
  'scheme' => string 'https' (length=5)
  'host' => string '%D0%BF%D1%80%D0%B8%D0%BA%D0%BB%D0%B0%D0%B4.%D1%83%D0%BA%D1%80' (length=61)
  'path' => string '/' (length=1)
  ...

array (size=7)
  'scheme' => string 'https' (length=5)
  'host' => string '%CF%80%CE%B1%CF%81%CE%AC%CE%B4%CE%B5%CE%B9%CE%B3%CE%BC%CE%B1.%CE%B5%CE%BB' (length=73)
  'path' => string '/' (length=1)
  ...

Instead they should be parsed to:

array (size=7)
  'scheme' => string 'https' (length=5)
  'host' => string 'пример.рф' (length=17)
  'path' => string '/' (length=1)
  ...

array (size=7)
  'scheme' => string 'https' (length=5)
  'host' => string 'приклад.укр' (length=21)
  'path' => string '/' (length=1)
  ...

array (size=7)
  'scheme' => string 'https' (length=5)
  'host' => string 'παράδειγμα.ελ' (length=25)
  'path' => string '/' (length=1)
  ...

Sorry to hassle you again folks, but I'm running the tests on the project and am coming up against an issue with functions.php line 360.

Numerous tests are failing with the same issue, but I'm focusing on the "http://example.org:8080/" test.

I've pasted the relevant code into http://sandbox.onlinephpfunctions.com/ so that I can test it against different PHP versions. The code is:

<?php
$uri = '//example.org:8080/';
$regex = '
          %^
            //
            (?: (?<user> [^:@]+) (: (?<pass> [^@]+)) @)?
            (?<host> ( [^:/]* | \[ [^\]]+ \] ))
            (?: : (?<port> [0-9]+))?
            (?<path> / .*)?
          $%x
        ';
var_dump(preg_match($regex, $uri, $matches));
var_dump($matches);

The error I'm getting is:

<b>Warning</b>:  preg_match(): Unknown modifier '
' in <b>[...][...]</b> on line <b>12</b><br />
bool(false)
NULL

Any advice would be appreciated. Thank you.