IPv6 URL causes "Error `Template parameter names *must* be separated`" error in m.request

[vikulin]

Bug Report

Current Behavior IPv6 URL causes "Error Template parameter names *must* be separated" error in m.request receiving IPv6 with [ ] symbols in URL. It can happen when flarum forum is installed using IPv6 host and it being used in URL. As result all clicks are throwing the same error in red box: "Oops! Something went wrong. Please reload the page and try again."

Steps to Reproduce

1. Install forum using IPv6 address (f.e. 202::a6a1:990a:cd27:4d9e:79)
2. Use any default parameters during installation, turn on debug in config.php file
3. Go to main page and click reload button or try to register new account

Expected Behavior All activities should complete

Screenshots

Environment

• Mithril: 2.0.4
• Flarum version: v0.1.0-beta.16
• Website URL: http://[202::a6a1:990a:cd27:4d9e:79]:8080/ through yggdrasil
• Webserver: apache
• Hosting environment: VM Ubuntu 20
• PHP version: 7
• Browser: any

php flarum info

root@ubuntu:/var/www/html/flarum# php flarum info
Flarum core 0.1.0-beta.16
PHP version: 7.4.3
Loaded extensions: Core, date, libxml, openssl, pcre, zlib, filter, hash, pcntl, Reflection, SPL, session, standard, sodium, mysqlnd, PDO, xml, calendar, ctype, curl, dom, mbstring, FFI, fileinfo, ftp, gd, gettext, iconv, json, exif, mysqli, pdo_mysql, Phar, posix, readline, shmop, SimpleXML, soap, sockets, sysvmsg, sysvsem, sysvshm, tokenizer, xmlreader, xmlrpc, xmlwriter, xsl, zip, Zend OPcache
+----------------------+------------------+--------+
| Flarum Extensions    |                  |        |
+----------------------+------------------+--------+
| ID                   | Version          | Commit |
+----------------------+------------------+--------+
| flarum-approval      | v0.1.0-beta.16   |        |
| flarum-bbcode        | v0.1.0-beta.16   |        |
| flarum-emoji         | v0.1.0-beta.16   |        |
| flarum-lang-english  | v0.1.0-beta.16   |        |
| flarum-flags         | v0.1.0-beta.16   |        |
| flarum-likes         | v0.1.0-beta.16   |        |
| flarum-lock          | v0.1.0-beta.16   |        |
| flarum-markdown      | v0.1.0-beta.16.1 |        |
| flarum-mentions      | v0.1.0-beta.16   |        |
| flarum-statistics    | v0.1.0-beta.16   |        |
| flarum-sticky        | v0.1.0-beta.16   |        |
| flarum-subscriptions | v0.1.0-beta.16   |        |
| flarum-suspend       | v0.1.0-beta.16   |        |
| flarum-tags          | v0.1.0-beta.16   |        |
+----------------------+------------------+--------+
Base URL: http://[202::a6a1:990a:cd27:4d9e:79]:8080
Installation path: /var/www/html/flarum
Debug mode: ON

Possible Solution There is an article with the clear explanation for a possible solution: https://stackoverflow.com/questions/63968329/error-template-parameter-names-must-be-separated

Additional Context More detailed error stack:

SyntaxError: Template parameter names *must* be separated
    at t.exports (http://[202::a6a1:990a:cd27:4d9e:79]:8080/assets/forum-55d936d3.js:1:66159)
    at http://[202::a6a1:990a:cd27:4d9e:79]:8080/assets/forum-55d936d3.js:25:103876
    at new Promise (<anonymous>)
    at Function.request (http://[202::a6a1:990a:cd27:4d9e:79]:8080/assets/forum-55d936d3.js:25:103853)
    at e.request (http://[202::a6a1:990a:cd27:4d9e:79]:8080/assets/forum-55d936d3.js:1:63247)
    at t.e.find (http://[202::a6a1:990a:cd27:4d9e:79]:8080/assets/forum-55d936d3.js:1:50192)
    at t.e.loadResults (http://[202::a6a1:990a:cd27:4d9e:79]:8080/assets/forum-55d936d3.js:52:109405)
    at t.e.refresh (http://[202::a6a1:990a:cd27:4d9e:79]:8080/assets/forum-55d936d3.js:52:109104)
    at HTMLButtonElement.onclick (http://[202::a6a1:990a:cd27:4d9e:79]:8080/assets/forum-55d936d3.js:52:105778)
    at _.handleEvent (http://[202::a6a1:990a:cd27:4d9e:79]:8080/assets/forum-55d936d3.js:25:102481)

[dead-claudia]

I'm leaning towards just adding the workaround like what's mentioned in the SO question to the docs. Probably something like a :host + host: "[::1]:8080" parameter - this also works for things like foo.com:1234. Given how rarely those variants are used in practice, I don't see it as worth the effort to support, especially when the workaround isn't all that complicated.

[vikulin]

I'm leaning towards just adding the workaround like what's mentioned in the SO question to the docs. Probably something like a :host + host: "[::1]:8080" parameter - this also works for things like foo.com:1234. Given how rarely those variants are used in practice, I don't see it as worth the effort to support, especially when the workaround isn't all that complicated.

@isiahmeadows , could you please be more specific in terms of m.request code examples how to do such workaround? If you suggest to change the m.request usage it would require more efforts in production code development. F e I counted flarum uses it 16 times:

root@ubuntu:/var/www/html/flarum# grep -o m.request . -R
./vendor/laminas/laminas-diactoros/CHANGELOG.md:m request
./vendor/laminas/laminas-diactoros/src/RequestTrait.php:m request
./vendor/middlewares/request-handler/README.md:m request
./vendor/middlewares/request-handler/src/RequestHandler.php:m request
./vendor/flarum/core/js/dist/forum.js:m.request
./vendor/flarum/core/js/dist/forum.js.map:m.request
./vendor/flarum/core/js/dist/forum.js.map:m.request
./vendor/flarum/core/js/dist/admin.js:m.request
./vendor/flarum/core/js/dist/admin.js.map:m.request
./vendor/flarum/core/js/dist/admin.js.map:m.request
./vendor/flarum/core/js/src/common/Application.js:m.request
./vendor/psr/http-message/src/RequestInterface.php:m request
./public/assets/forum-78abc0f0.js:m.request
./public/assets/forum-78abc0f0.js.map:m.request
./public/assets/forum-78abc0f0.js.map:m.request
./public/assets/admin-48c4593e.js.map:m.request
./public/assets/admin-48c4593e.js.map:m.request
./public/assets/admin-48c4593e.js:m.request

[dead-claudia]

@vikulin I'm suggesting something like this:

m.request("http://:host/some/path", {
    params: {host: "[202::a6a1:990a:cd27:4d9e:79]:8080"},
    // ...
})

Shouldn't be too difficult to patch.

Note: I strongly recommend you move origin-relative URLs like /some/path for these use cases as IP addresses really aren't that stable in practice, and you can much more easily move it around to other IPs if needed (you can avoid the need for source changes with it)f.