The generic URI syntax actually specifies that any path segment within a URI can be divided up into parts by semicolons (or commas), and suggests using key=value as parameters within that segment.
For
example, the semicolon (";") and equals ("=") reserved characters are
often used to delimit parameters and parameter values applicable to
that segment. The comma (",") reserved character is often used for
similar purposes. For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same
There’s no thought given as far as I can see to the relative URL concepts this matrix proposal covers, but the idea of adding key=value data in this format is supported by the RFC, and indeed in a way that supports further adding sub resources below the current one.
Which, by the way, this matrix relative URL proposal seems to ignore - how is ./subpage resolved relative to /map;x=250;y=582 ?
Many comments so far seem to imply (perhaps not intentionally) that this syntax was intended only on the "right side" of the URI, but you can think of it more as adding qualifier-like information to (potentially) each path segment. So in /com/foo/bar you could further qualify foo (perhaps as /com/foo;color=yellow/bar). This can be combined with a (definitionally trailing) query string as well. Someone noted that Spring implements some support for this; the Eclipse Foundation's Jersey (Java REST toolkit) does as well if I remember right.
That's how I use matrix params in one of my Angular projects - these are very handy to put segment filter params into instead of query params. When you have parallel routes (page/dialog) and filtering everywhere, URLs stay much easier to reason about.
Browser and server and language defaults. Back in the CGI-BIN days there were loads of apps using "exotic" options in the URL. IMO when ASP3 and PHP3 were popular (I was there Gandalf!) the world started to normalize around '&'
Alan Kay kind of said something along those lines, in that
he envisioned the world wide web to be more integrative.
If we include this with Matrix URIs, we could have a scheme
format that could work with remote data/objects in a convenient
and logical way. RESTful APIs do not seem to be quite the same
though. Like some universal API ... not sure how it would look.
If my query would be "weather?" then any API should understand
this to mean I'd like to return the local weather. But as an
API. Naturally we have AI now so any such queries become trivial
at all times, but this is still not quite what was meant. We
kind of limited things here because "all external input may be
malicious". This then meant no further development in this area,
because "too dangerous". Every time I try to use JavaScript to
read a local file, I am reminded of that as limitation. They
did not think that there are valid, non-malicious use cases,
so I am using ruby and python rather than JavaScript (I could
use node, but it kind of feels ... so dirty when using it).
The cool thing is, there is so little "ossification surface" in URLs that this proposal could still be implemented today. The only thing not natively supported by browsers is the relative URL syntax, but even that could be added by some JavaScript or server-side rewrites if desired.
In every monolithic Java Jersey server I worked in there was always at least 1 class using @MatrixParam instead of the query param equivalent. No one could ever answer me why or who because it was always written in a project before it migrated to git.
Wondered about that as well. There are a few more word errors like this one, so I guess the text was captured using early dictation/speech recognition software?
Think “how do I implement a search engine whose interface is visible in the browser address bar?” This was a reasonable question on the early web. And that’s why they are called query params.
The question mark indicates you’re making a query. And the ampersand is a boolean operator. You could imagine query params implementing | in addition to &.
I think to non-techies the semi-colons are still more intuitive - I often see non-technical people mess up the ? and &, either by using just one of them or by getting them the wrong way around.
I'm certain I've seen websites which used semi-colons rather than question marks and ampersands for query parameters. The Jehovah's Witnesses website used to, many years ago. I believe that one of the reasons behind this design was that it meant that there were no special characters which needed to be escaped in HTML. This design works fine for links, but not for forms, which will generate normal URLs containing question marks and ampersands. I suppose you can use POST-Redirect-GET forms, and generate your own URLs using semi-colons.
I just found out you may - even in current HTML use entity references in attribute values, it’s just you don’t have to anymore, when the ampersand is not ambiguous.
The spec states it as: “Attribute values are a mixture of text and character references, except with the additional restriction that the text cannot contain an ambiguous ampersand.”
Whereas in the the days before HTML5 this has been mandatory.
> HTML 4.01 Specification – Appendix B.2.2 “Ampersands in URI attribute values”
> Unfortunately, the use of the “&” character to separate form fields interacts with its use in SGML attribute values to delimit character entity references.
You're supposed to escape & anywhere in HTML, not just in text nodes. If you don't (and many don't) it'll probably work, but browser first tries to interpret it as a start of an entity anyway. Even if it is inside a href etc.
In HTML escaping & is kind of optional and the browser just tries to figure out what you mean, but if you are doing things properly you should use & in href attributes.
If you're relying on HTML forms being filled in to generate queries, the browser will always generate standard query parameters with a question mark and ampersands. But if you're making your own links, you can generate them however you like. Semi-colons should work fine, though you may need to write your one URL parsing functions.
I think some browsers display the query params muted compared to the part before (or maybe I’m confusing it with the behavior that the domain is highlighted to prevent phishing?). But technically, you can just parse the request url however you want. I also think it shouldn’t matter with regards to any caching layers inbetween.
Just one minor one why you might not want to. HTTP{S}? handling objects understand the URL parameter syntax and do parsing for you, so when you write a request handler, you are dealing with structured dictionaries of request headers and URL parameters.
You can use it if you want, but the browser doesn’t help you at all. It can’t automatically turn a form into a matrix URI, and it can’t do anything useful with relative matrix URIs.
You're saying that as if developers have cared about the platform in the past twenty years. Use JS, everything is possible, even turning a div into a link, apparently.
The generic URI syntax actually specifies that any path segment within a URI can be divided up into parts by semicolons (or commas), and suggests using key=value as parameters within that segment.
http://tools.ietf.org/html/rfc3986#section-3.3
There’s no thought given as far as I can see to the relative URL concepts this matrix proposal covers, but the idea of adding key=value data in this format is supported by the RFC, and indeed in a way that supports further adding sub resources below the current one.Which, by the way, this matrix relative URL proposal seems to ignore - how is ./subpage resolved relative to /map;x=250;y=582 ?
The whole third part of the posted document is about relative urls.
Right - the URI spec, on the other hand says nothing about this idea of a relative URL modifying one or more of these paths segment parameters.
Many comments so far seem to imply (perhaps not intentionally) that this syntax was intended only on the "right side" of the URI, but you can think of it more as adding qualifier-like information to (potentially) each path segment. So in /com/foo/bar you could further qualify foo (perhaps as /com/foo;color=yellow/bar). This can be combined with a (definitionally trailing) query string as well. Someone noted that Spring implements some support for this; the Eclipse Foundation's Jersey (Java REST toolkit) does as well if I remember right.
That's how I use matrix params in one of my Angular projects - these are very handy to put segment filter params into instead of query params. When you have parallel routes (page/dialog) and filtering everywhere, URLs stay much easier to reason about.
Semicolon is also nice on the eyes compared to '&' we're used to today.
Why in the world this didn't gain traction?
Browser and server and language defaults. Back in the CGI-BIN days there were loads of apps using "exotic" options in the URL. IMO when ASP3 and PHP3 were popular (I was there Gandalf!) the world started to normalize around '&'
Alan Kay kind of said something along those lines, in that he envisioned the world wide web to be more integrative.
If we include this with Matrix URIs, we could have a scheme format that could work with remote data/objects in a convenient and logical way. RESTful APIs do not seem to be quite the same though. Like some universal API ... not sure how it would look.
If my query would be "weather?" then any API should understand this to mean I'd like to return the local weather. But as an API. Naturally we have AI now so any such queries become trivial at all times, but this is still not quite what was meant. We kind of limited things here because "all external input may be malicious". This then meant no further development in this area, because "too dangerous". Every time I try to use JavaScript to read a local file, I am reminded of that as limitation. They did not think that there are valid, non-malicious use cases, so I am using ruby and python rather than JavaScript (I could use node, but it kind of feels ... so dirty when using it).
The cool thing is, there is so little "ossification surface" in URLs that this proposal could still be implemented today. The only thing not natively supported by browsers is the relative URL syntax, but even that could be added by some JavaScript or server-side rewrites if desired.
This is completely redundant w.r.t. URL parameters: ?foo=bar&etc=whatever ...
There is no need to have two competing keyword-value-list (KVL) formats in the same context.
Wasn't the matrix proposal earlier (or in parallel) to the query string one? Or did they have different intended meanings from the start?
It did, in at least one way: https://docs.spring.io/spring-framework/reference/web/webmvc...
In every monolithic Java Jersey server I worked in there was always at least 1 class using @MatrixParam instead of the query param equivalent. No one could ever answer me why or who because it was always written in a project before it migrated to git.
Whenever the article mentions 'pause', it means 'parse', right?!
Wondered about that as well. There are a few more word errors like this one, so I guess the text was captured using early dictation/speech recognition software?
I quite like the semi-colons. I wonder how we ended up with the slightly unwieldy ?foo=bar&some=thing
Think “how do I implement a search engine whose interface is visible in the browser address bar?” This was a reasonable question on the early web. And that’s why they are called query params.
The question mark indicates you’re making a query. And the ampersand is a boolean operator. You could imagine query params implementing | in addition to &.
I think to non-techies the semi-colons are still more intuitive - I often see non-technical people mess up the ? and &, either by using just one of them or by getting them the wrong way around.
I chuckled once when driving having a radio adverts announce "enter in your web browser something.com slash question-mark prize ampersand win to win!"
I'm certain I've seen websites which used semi-colons rather than question marks and ampersands for query parameters. The Jehovah's Witnesses website used to, many years ago. I believe that one of the reasons behind this design was that it meant that there were no special characters which needed to be escaped in HTML. This design works fine for links, but not for forms, which will generate normal URLs containing question marks and ampersands. I suppose you can use POST-Redirect-GET forms, and generate your own URLs using semi-colons.
Seems Like the recommendation changed from supporting ; and & to only using &.
Thinking about it, it is a little surprising as, if I remember correctly, in HTML source you should encode & as & right?
& as an escape character only applies to text nodes. Of course, if you want to display the URL on a page, you have to escape it, but not in the href.
I just found out you may - even in current HTML use entity references in attribute values, it’s just you don’t have to anymore, when the ampersand is not ambiguous.
The spec states it as: “Attribute values are a mixture of text and character references, except with the additional restriction that the text cannot contain an ambiguous ampersand.”
Whereas in the the days before HTML5 this has been mandatory.
> HTML 4.01 Specification – Appendix B.2.2 “Ampersands in URI attribute values”
https://www.w3.org/TR/html401/appendix/notes.html#h-B.2.2
> Unfortunately, the use of the “&” character to separate form fields interacts with its use in SGML attribute values to delimit character entity references.
That's the same as main body text isn't it? And you have to be able to use them so you can escape " just like you have to escape < in main text.
HTML5 standardized how to interpret formerly invalid documents because it was more important to be consistent than to be correct.
You're supposed to escape & anywhere in HTML, not just in text nodes. If you don't (and many don't) it'll probably work, but browser first tries to interpret it as a start of an entity anyway. Even if it is inside a href etc.
That is incorrect. Entities apply to attributes.
In HTML escaping & is kind of optional and the browser just tries to figure out what you mean, but if you are doing things properly you should use & in href attributes.
Is there any reason we couldn't just use that anyway?
If you're relying on HTML forms being filled in to generate queries, the browser will always generate standard query parameters with a question mark and ampersands. But if you're making your own links, you can generate them however you like. Semi-colons should work fine, though you may need to write your one URL parsing functions.
Iirc in java I managed to parse those just fine. Ages ago though.
I also recall actually seeing some web pages somewhere using semicolon, possibly IBM stuff.
I think some browsers display the query params muted compared to the part before (or maybe I’m confusing it with the behavior that the domain is highlighted to prevent phishing?). But technically, you can just parse the request url however you want. I also think it shouldn’t matter with regards to any caching layers inbetween.
Just one minor one why you might not want to. HTTP{S}? handling objects understand the URL parameter syntax and do parsing for you, so when you write a request handler, you are dealing with structured dictionaries of request headers and URL parameters.
You can use it if you want, but the browser doesn’t help you at all. It can’t automatically turn a form into a matrix URI, and it can’t do anything useful with relative matrix URIs.
You're saying that as if developers have cared about the platform in the past twenty years. Use JS, everything is possible, even turning a div into a link, apparently.