relative URI has wrong directory and file values

[inta]

If you create a URI object without a path (e.g. only with query string or fragment identifier), directory and file are not set to the current dir and file name.

// window.location: http://example.com/a/b/c
var uri = new URI('?foo=bar')
uri.get('scheme')    // expected: "http"        actual: "http"
uri.get('host')      // expected: "example.com" actual: "example.com"
uri.get('directory') // expected: "/a/b/"       actual: "/"
uri.get('file')      // expected: "c"           actual: ""

If I read RFC 3986 correctly it should fall back to the current URI.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/35995455-relative-uri-has-wrong-directory-and-file-values?utm_campaign=plugin&utm_content=tracker%2F22069&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F22069&utm_medium=issues&utm_source=github).

[boppy]

I think this is intended since you would have to merge data otherwise:

// window.location.href = 'https://foo.bar/b/a.z?one=two&three=4'
var uri1 = new URI('?five=VI'); // Should URI append another question mark here?
var uri2 = new URI('?three=III'); // will that override or make an array or <...>?
var uri3 = new URI('&three=III'); // ...

In your situation I would consider:

var baseUrl = 'https://foo.bar/b/a.z?one=two&three=4'; // window.location.href
var myQueryString = '?foo=bar&one=1';
                                        //--> [ removes ? and & from the very left ]
var myQueryStringObject = myQueryString.replace(/^[\?&]/, '').parseQueryString();
var uri = new URI(baseUrl);
// With that setData(..., true) you tell the URI instance to keep existing keys but allow to overwrite their values.
uri.setData(myQueryStringObject, true);

alert(uri.toString());
// https://foo.bar/b/a.z?one=1&three=4&foo=bar

[inta]

I know that I can work around this issue – that's what I'm currently doing – but I think it's desired to get get the correct behaviour from URI. That's what I would expect.

If the current status is really intended, I think it should be documented.