With URI.js, it's easy to SET parameters.

I've read all the docs and hope I'm missing something, but I can't find a good way to GET the query string parameter value.

What I'm having to do now is this:

if (url.search(true).hasOwnProperty("my_parameter_name")) {
  console.log("parameter value is" + url.search(true).my_parameter_name);
}

Is there a better way?

First, I apologize if this should really be an issue instead of a PR, so that the solution could be properly planned in advance.

I work on a product is required to accept URIs which may or may not be properly encoded and reformat them as properly-encoded URIs. This is a hard problem to solve on our own, and so URI.js has been a godsend. Unfortunately, the most common type of URI we handle is a URN; and URI.js does not currently have anything like recodePath for URNs. This patch implements a recodeURNPath method for URNs and calls it while normalizing a URN path.

This PR might carry a risk with it, unfortunately. There is some equivocation in the documentation about the difference between URNs and URIs, which is reflected in the overall structure of URI.js:

URLs are used to address the individual resources of your website. URNs are usually used for hooking into other applications, as mailto:, magnet: or spotify: suggest. While RFC 3986 defines the structure of an URL in depth, URNs are not. The structure (and meaning) of URNs are up to their distinct specifications.

Technically, URN refers to a very specific thing: Uniform Resource Names as defined by RFC 2141 (the syntactic requirements of which are implemented in this patch). Though there is some degree of freedom to the structure of URNs in a specific namespace, they cannot break the rules laid out in 2141 (such as which characters are valid in a URN). In addition, this means that mailto: and spotify: URIs are not actually URNs at all (and in fact, the RFC defining mailto: scheme, RFC 2368, calls it a URL).

I think URI.js is drawing its inspiration from this paragraph in RFC 3986 (which is mentioned in the quoted documentation above):

A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name.

The problem here is that even this is still a purely semantic distinction, while the distinction between URNs and URIs as implemented in URI.js is syntactic: URLs are anything that looks like protocol://user:password@hostname/path/with/slashes?query=string and URNs are anything that looks like scheme:path:with:colons?query=string.

All this is to say: introducing the syntactic requirements to normalize real URNs as defined in RFC 2141 may or may not actually apply to the things URI.js treats as URNs.

That said, in practice I think the risk isn't very significant. For one, users of URN-ish URIs already could not rely on URI.js for proper normalization of paths, and so I see no harm in URI.js applying its best effort. If a consumer needs a particular kind of syntax for their custom URI scheme, they always have had to implement that themselves, and so nothing changes here.

Thanks for fixing #75 – that fixed the specific cases that I raised.

However, there are several more things that I think aren’t quite right about .relativeTo().

May I humbly suggest the attached changeset?

Hopefully the test cases that I have added and changed speak for themselves, but I’m happy to explain my rationale if anything is controversial, or to be corrected if I’m being silly :).

Hi,

To have easy interactions between json objects and Search/Query serialisation, I addQuery and removeQuery elements always providing a list. This works great except it removeQuery, not removing the last value of a multi-value GET variable, if this value is specified via a singleton list (which is not illegal).

I am to provide a pull request fixing this small issue.

URI("").segment(["%"]);
// => URIError: URI malformed

URI("%25").segment();
// => ["%25"]

This makes me want to cry.

The whole point of having a library to handle URIs is that the user of the library shouldn’t have to think about how to encode or decode URIs.

For example, if I know that there is a resource called “Business Plan (90%)” in a directory called “My Extremely Dull Documents”, I ought be able to create a relative URI referencing that resource with syntax somewhat like this:

URI("").segment(["My Extremely Dull Documents"], ["Business Plan (90%)"]);

which would then produce a URI whose text representation is: My%20Extremely%20Dull%20Documents/Business%20Plan%20%2890%25%29.

Similarly when parsing the resulting URI I ought to be able to do something somewhat like:

URI("My%20Extremely%20Dull%20Documents/Business%20Plan%20%2890%25%29").
    segment();

And get back the original strings: ["My Extremely Dull Documents"], ["Business Plan (90%)"].

I know I can use URI.encode and URI.decode on the path segments, but that requires the user to remember to do so, and to know and remember which of the several encoding schemes are used for which parts of the URI, so that’s pretty error-prone :(.

uri = URI("208.113.212.187") uri.path -> 208.113.212.187 _string -> ""

It may not be RFC complaint, but no-one adds http:// to their IP addresses.

The error seems to be coming because of the following code:

f=Function("return this")()

Error:

Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' chrome-extension-resource:".

Reduced case chrome extension: http://dl.dropboxusercontent.com/u/42214070/urijs-security-issue.crx

Now: http://example/ returns example from tld()

After: http://example/ returns (empty string) from tld()

I would prefer returning null but the other checks returns an empty string...

https://github.com/bower/bower.json-spec#main explicitly states that only one file per filetype should be listed in main:

The entry-point files necessary to use your package. Only one file per filetype.

"main": [
  "src/URI.js",
  "src/IPv6.js",
  "src/SecondLevelDomains.js",
  "src/punycode.js",
  "src/URITemplate.js",
  "src/jquery.URI.js",
  "src/URI.min.js",
  "src/jquery.URI.min.js",
  "src/URI.fragmentQuery.js",
  "src/URI.fragmentURI.js"
],

I would expect only one .js file here.

// The following works (when I think it shouldn't)
var uri = URI('http://example.com:robots.txt');

// Even this works
console.log(uri.port()); // Will output 'robots.txt'

// This does not work however...
var uri = URI('http://example.com');

// ...since this will (correctly) throw an error
uri.port('robots.txt');

Could we look into adding the same validation of the URI port when constructing URI instances from strings as we have when calling the uri.port method?

Installed via bower and configured RequireJS:

paths: {
  urijs = '/dist/uri.js/URI.min'
}

We have a build system that copies only URI.min.js to our deploy path.

However, once this js file has loaded, RequireJS hits a 404 trying to find:

http://127.0.0.1:8080/URI.js?bust=1443743941152

I'm not sure what's causing this - I assume "URI" is a package defined within that same file, so I don't understand why require is going out and trying to find it.

Update: I've tried to reproduce this by cloning the repo and hitting a basic html file with requirejs. While I am able to get the file to load, the example on your README throws a "URI is not a function" error, and the object I'm given has properties best and noConflict - it seems to be giving me the IPv6 module...

https://pste.me/#/BdSlk

Hello. Can i change params separator?

var template = new URITemplate("http://example.org/{file}");
var result = template.expand( {file: ['param1', 'param2', 'param3'] } );
result === "http://example.org/param1,param2,param3";

Can i use + instead comma? Like this: result === "http://example.org/param1+param2+param3";

After version 1.18.11 of urijs, an invalid port exception is thrown if the uri is constructed with a port that isn't valid. This check is useful to avoid having an invalid value as a port, increasing the correctness of the generated URI, but makes impossible to use the library when working with url templates.

Before 1.18.11, the following code snippet was possible:

const uri = new urijs('https://github.com:{port}');

After 1.18.11, the same code snippet throws the invalid port exception.

There're several possible solutions to this problem, in case there's the desire to support URI templates.

1. Make port check optional by passing an options object to the constructor:

const uri = new urijs('https://github.com:{port}', { ensureValidPort: false });

2. The second idea that comes to my mind is to throw the exception not when the URI is created but when it's converted to a string. My hypothesis here is that uri.toString() or uri.valueOf() might be the last calls to the urijs library before the constructed URI is used.

const uri = new urijs('https://github.com:{port}'); // valid, no exception is thrown
// do stuff here
const resp = await fetch(uri.toString()); // here an exception will be thrown if the port is still invalid

3. There might be also other valid options.

Would such change be considered for this library?

Steps to Reproduce:

1. Have an HTML payload where server gives response header content-type: text/html;charset=Shift_JIS
2. Include the URI.js file with a script tag, use a compressed version of URI.js (not sure if same issue happens on the uncompressed one)

Unfortunately I can't find an easy way to give a link for this easily, but if it's necessary I could produce one maybe with codesandbox.

Expected:

The Javascript include should run, there should be no errors in the console

Actual:

The Javascript fails to parse with an error in the logs:

Uncaught SyntaxError: Unexpected token ':'

Root Cause:

There are non-ASCII characters inside of a Regular Expression in a couple places, example: https://github.com/medialize/URI.js/blob/b655c1b972111ade9f181b02374305942e68e30a/src/URI.js#L231

The non-ASCII characters «»“”‘’ are interpreted differently when the charset is set to Shift_JIS on the HTML page as a response header, and it causes the regular expression not to be closed properly, running into the next lines making a syntax error in the middle of the JSON. The same behavior is seen in Firefox and Chrome, I have not checked Edge.

Proposed solution:

Don't use non-ASCII characters which are unsafe when charsets are changed on the page, instead use a String that will be constructed with escaped characters:

  URI.find_uri_expression = new RegExp("\\b((?:[a-z][\\w-]+:(?:\\/{1,3}|[a-z0-9%])|www\\d{0,3}[.]|[a-z0-9.\\-]+[.][a-z]{2,4}\\/)(?:[^\\s()<>]+|\\(([^\\s()<>]+|(\\([^\\s()<>]+\\)))*\\))+(?:\\(([^\\s()<>]+|(\\([^\\s()<>]+\\)))*\\)|[^\\s`!()\\[\\]{};:'\".,<>?\xab\xbb\u201c\u201d\u2018\u2019]))", "ig");

One other place: https://github.com/medialize/URI.js/blob/b655c1b972111ade9f181b02374305942e68e30a/src/URI.js#L238

Could update to this:

    trim: new RegExp("[`!()\\[\\]{};:'\".,<>?\xab\xbb\u201c\u201d\u201E\u2018\u2019]+$"),

These are 2 places, there might be more.

Hello, I found an error that seems to be related to URIjs and ES6. Someone from 2016 [288] seems to have found this previously and couldnt replicate but here are the steps. Could you help me understand how to get around this?

Error: node_modules/stellar-sdk/lib/server.d.ts:2:8 - error TS1259: Module '"/node_modules/@types/urijs/index"' can only be default-imported using the 'allowSyntheticDefaultImports' flag

2 import URI from "urijs";
         ~~~

  node_modules/@types/urijs/index.d.ts:26:1
    26 export = URI;
       ~~~~~~~~~~~~~
    This module is declared with using 'export =', and can only be used with a default import when using the 'allowSyntheticDefaultImports' flag.

To replicate

1. ng new AppName
2. npm install --save stellar-sdk
3. add the SDK to the app within angular.json's build scripts: ["./node_modules/stellar-sdk/dist/stellar-sdk.min.js"]
4. run the app to see the error

I'm not sure how much URI.js tries to be in sync with the Web API URL, but even after ac43ca8f80c042f0256fb551ea5203863dec4481 , there's still a difference between URI.js and URL when it comes to slashes, e.g. when dealing with relative URLs that have a protocol (verified in Chrome 93.0.4577.82, Safari 14.1.2 and Firefox 92.0.1):

> URI.version
< '1.19.7'
> new URI("https:index.html", "https://github.com").toString()
< 'https://index.html/'
> new URL("https:index.html", "https://github.com").toString()
< 'https://github.com/index.html'

This is caused by the newly introduced regex. It checks for zero or more slashes. Browsers seem to check for at least two slashes, if there's a base.

To complicate things, browsers behave differently when no base is given or when the protocols don't match. Then they rather seem to correct typical typos or lazy users (that's at least my assumption):

> new URI("https:index.html").toString()
< 'https://index.html/'
> new URL("https:index.html").toString()
< 'https://index.html/'

I didn't check whether this is spec'ed somewhere for the URL Web API, but rather wanted to point out this suspicious aspect of the regex.

The good thing: as URI.js 1.19.6 threw an error for the above calls with a base, this issue shouldn't cause a regression for consumers.