I'm sure you've seen this anytime you go to any website or type in a URL into
the browser bar, it starts showing HTTP or HTTPS if the website is encrypted.
But what is the point of this?
Well, the simple answer is that the HTTP tells the browser what protocol
or type of content it's about to load.
So most of the time it's going to be a website,
which uses the HTTP protocol.
But I mean, what's the point of this?
Of course, it's a website, it's the web browser.
What else would you be using it for?
And in fact, many web browsers, these days don't even bother showing the
whole HTTP thing, it just hides it.
And if you click on it, sometimes it will show the full thing, but it is kind
of pointless to show most of the time.
However, it isn't always necessarily just going to be HTTP or HTTPS.
There are other ones you may have occasionally come across.
For example, you may have come across one of several software programs that
seem to have their own protocol links.
For example, Chrome, Spotify, Steam, Zoom, and you might've seen these
and just not really thought anything of it, or maybe have wondered,
what is that all about?
And are there other weird protocol links that are not just HTTP?
And that is the point of this video because yes, there are
plenty of them you may have never heard of before or never noticed.
So first we'll go over what exactly these different URL
protocols or schemes are for.
And it's actually pretty self-explanatory.
So it won't take long to do that once you see it.
And then we can go over some more examples, you might find interesting.
As well as how to officially register these things, because yes, there is
an official registry of some of them, some of them aren't quite official.
It's kind of interesting to see how the, all that intertwines,
so we'll go over all that.
So first the basics of these URL schemes or URL protocols, you might see them
called a couple of different things.
Basically it is simply a identifier that goes in front of a link that
basically tells a program that is
activating the link, what type of content it is going to encounter, and
therefore what program or what method it should use to open that particular link.
Usually by default, if it's a web address, it's going to be HTTP.
And that's probably what the operating system will assume.
If you just type it without that.
But you could, for example, put a link, like I mentioned, like Chrome or Spotify
or Steam, and these links may tell the operating system, no, you need to actually
open this link with Steam and then it will pass that URL to steam as it opens.
Let me give you an example.
So say you're on the web version of Steam, the gaming platform.
And you are looking at your inventory of items.
And this item is for Team Fortress Two, for example, and there is a
link to inspect the item in game.
Now, obviously that is a link that is supposed to take you
into a game, not a website.
So how does that work?
Well, if you look at it, the link is actually a steam:// link.
And then it has some information about the app that's going to run and
then some information about the item.
And then steam will process it, and then open up the game that
is encoded in the URL as well.
So it knows what to do with all this information.
And then it'll open up the game directly and then show you the item.
Now how it exactly knows what program goes with what protocol I'll mention later.
So a really common use of these different protocols is a website that
is for a particular piece of software may have a specialized link that is
used to have one link on the website that opens directly to the part of the
software that they want to show you.
For Spotify, the example is pretty obvious, it tells the program
what song to open and play.
And for Zoom, it tells Zoom what meeting to join, stuff like that.
The Chrome example is a little bit different.
That's for the setting pages in Chrome and in Microsoft Edge, they have the
Edge one, but basically if you go into the settings, it will begin the
website URL with Chrome://, and then like settings or something like that.
And that's simply because you're not actually going to a website on the
internet, it's within the program itself.
So it makes sense that it's going to begin with that protocol.
And then also that allows people, if they do want to link to a particular
settings page in Chrome, they can put that link on a website and
it'll open in Chrome to that page.
And there are a ton of these different ones, some official, some unofficial I'll
describe what that exactly means later.
And there's actually a Wikipedia page listing most of them, and we're
not going to go over all of them.
Just some of the more interesting ones.
But the thing I want to quickly explain here is you may see,
it says "URI schemes", not URL.
You might be wondering what's the difference for the purpose of this
video and 99.9% of the time a URI is the same exact thing as a URL.
It's kind of like squares and rectangles.
All URLs are URIs, but not all URIs are URLs.
URL stands for uniform resource locator and URI stands for a
uniform resource identifier.
And the only other type of URI is a URN, uniform resource name.
And I'm not going to get into the difference of what these exactly are.
It's really semantics basically, but just know that 99.9% of the time, a URL
is the same exact thing as a URI, and anytime you see in this video, just know
that they're the same for this purpose.
All right.
So enough with that tangent, let's go over some more of these different URL
protocols you may have actually seen before, they're relatively common.
So one is the file:// protocol.
This is for local files.
So actually, if you just type into the web browser C:/ it'll actually
probably show you your local C: drive.
And if you type in a file://, and then the C: directory, it'll
show you the exact same thing.
So basically this is just a way to kind of browse files on your computer
using a web browser with this protocol.
Another one is the About:// protocol.
This is kind of similar to the other Chrome or Edge one where it basically
just kind of shows settings or info about a particular web browser locally.
Another one you might come across regularly is the extension:// or
Chrome-extension:// protocol, depending on what browser you're using, that
is for a particular extension.
Usually like the settings menu of an extension that might
be installed in your browser.
So if you were to right click and go to the settings page or maybe an
actual menu that is how the extension operates, it'll probably show that page
is having a extension:// protocol prefix.
Another good one you might've seen before, and never really realized
how it works are magnet:// links.
These are really common on BitTorrent downloads.
So basically this encodes a bunch of information, instead of a
torrent file that you download,
it basically is a way to send all the information about that torrent
that needs to be downloaded directly to the BitTorrent software without
having to download any kind of file.
It just all gets passed to the software immediately.
And another one I want to mention is a little bit different, which is the MailTo:
Now this is not one that goes in front of a URL per se, but
actually an email address.
So it's not MailTo://, but rather just mailto: and how this one works is if
you're putting a link on a website.
You put mailto: and then some email address.
And then if someone clicks on that link, it will open whatever default mail
program that person has on their computer.
And it will populate the "mail to" field with the email address in that link.
Before we go into how these different protocols come about, let me go
over some examples that are specific to Microsoft and Windows that you
might find kind of interesting.
One of them is the ms-clock:// protocol.
Yes.
if you go into the browser and type in ms-clock:// it will open
up the clock timer app in Windows.
Another one is the ms-calculator://.
You can open a calculator using a link.
Yes.
Kind of funny, but it's true.
Now for these two, it doesn't seem like you can actually
pass any parameters into it.
So, unfortunately it's not like you can type in
ms-calculator://1+1, and then it'll open up the calculator and do it.
I don't think you can do that.
Or at least I have found a way.
So basically these seem to just be to simply open that app.
Another one is the ms-windows-store:// protocol.
This one actually does pass parameters and it basically opens up certain apps or
links in the Microsoft Store and windows.
So a lot of times it's, there'll be for a specific app page.
You kind of get the idea.
Also, it seems like pretty much all of the different Microsoft Office suite
programs have their own protocol.
So if you type in ms-word:// it'll open up Microsoft word, same thing for
Excel or Access the database program or PowerPoint, pretty much all of
them seem to have their own thing.
And the final example here is the ms-settings:// protocol.
There's actually a few of these that are really related.
So if you just type in ms-settings:// it'll bring up the Settings in Windows.
And there's actually a couple more that are more specific to submenus.
For example, ms-settings-privacy, we'll bring up the privacy menu
or ms-settings-bluetooth will bring up the Bluetooth one.
And you could probably guess what some of the other ones are.
So yeah, pretty cool ones you might not have realized were there before.
Alright so now let's get into explaining how these different protocols come to be.
As you probably saw, there are a whole bunch of these, some of them
official, some of them unofficial.
First, let's go over the ones that are official.
And basically there are two different types, well three,
but I'll mention the first two: permanent or provisional schemes.
And when a company or a software goes to use one of these different
protocols, really they can name it whatever they want, they can
create it however they want.
And again, they don't have to register it, but if they do choose to so it will
be more recognized by other programs and not be taken by another program,
there are guidelines created by the IETF internet engineer taskforce, for how
you can submit it as an official one.
For one to be considered permanent, it's mostly going to be for a new
internet standard that is going to be basically used by pretty much
any kind of program out there.
It's not just basically restricted for use of one piece of software.
So the Steam one or the Spotify one that one's not going to be permanent because
it's not a internet wide standard.
It's only going to be used by Spotify or Steam, those softwares.
On the other hand, we have some of the examples are more for like a specific
piece of software and those are going to fall under the provisional category.
And the way this one is described in the guidelines is:
"Provisional registration can be used for schemes that are not part of any
standard, but that are intended for use or observed to be in use that is
not limited to a private environment within a single organization."
And what this means in plain English is it's a protocol that's not going
to be universally used by all sorts of different programs forever or anything,
but it's still common enough to warrant a registration because people might
probably still be using it relatively often, and it's probably for a big
company or common piece of software.
For example Spotify, yeah, people share links with Spotify all the time,
so it makes sense to register it.
So other companies don't create their own one called Spotify for some reason.
Now there is a third category called historical, which you can
probably guess what it's for.
It's mostly for protocols that are really not common anymore.
So it's not really important to support them.
One of them is fax for example.
But now let's get to a pretty fun part, which is talking about
unregistered or private protocols.
So obviously all the ones we kind of mentioned, and you'll see
registered are by big organizations,
cause you know, it's kind of a lot of work to go through the
process of registering it, you have to follow all these guidelines.
It probably takes a lot of time and effort, but you don't actually
have to go through with all that.
Instead, when a program is installed, it can simply add its own protocol
into the registry and then be supported by the operating system.
One example is streamdeck://, or Zoomus:// you might not realize that the
zoom one is not actually an officially registered one, but it still works.
I imagine that might become a provisional one, they might register at some point
because it is really popular now.
But Stream Deck is a really good example because it's
you know, kind of a popular device and I actually have it installed in mine
and it allows you to link to stuff within that software, but it's not
officially registered, but it still works.
And the way these are added to the computer and how the computer knows
what the different protocols are for is in the registry of Windows.
So if you open up the registry editor and go to the Computer/HKEY_Classes_root
directory, and in here, you'll see a lot of different registry keys, not
all of these are protocols, but all the protocols will be in this one.
And you'll see some of the ones we already mentioned like Steam.
streamdeck.
They're all going to be in here.
And the structure of these different keys, is they're going to have
different sub keys for Shell and then Open and then Command.
And then in that one it'll show what actually gets executed if this protocol
is called with the browser, for example.
So with Steam, you can see here that it has the file path to the steam application
file and then a %1, which just means that it takes some parameter after the
://. So that's what some of that information about the item might be
for example, or what page in Steam is supposed to open that sort of thing.
And actually as a really fun example, you might not have known
that steam has a secret console tab.
So if you actually go into the browser and type steam://, and then open/console,
it will actually open the secret tab.
And there are a bunch of different commands you can look up.
I mean, they're not particularly useful, it's more of just a curiosity but
still pretty cool that that's there.
And if you're wondering, yes, you can actually create your very own protocol.
And actually that's what another YouTuber named Enderman did in another video,
which kind of tipped me off to this.
He basically went through and created his own, which was called CMD, and what
he showed is basically all you have to do is create a registry key with the
same exact structure as the other ones with the open>shell>command and then it
will work like any of the other ones.
And I'll have a video pop out if you want to go check that out.
Now, unfortunately in a lot of cases, making one of these is not going
to be particularly useful, because even if you create one that takes
in a parameter with the %1, then the browser is going to pass the entire
URL into whatever program you open.
And basically what that means is you'll have to write probably
an extra additional program that is going to parse out the URL.
If you want to do any actual fancy stuff with this protocol
that you create yourself.
Or you could just keep it simple and have one that simply opens up some
program, and that would just work.
But still at this point, you pretty much have a full understanding of how these
different protocols come to be, and where they're stored and how they're created.
So hopefully you just found it interesting.
And if you did be sure to let me know down in the comments what you thought if you
guys want to subscribe, be sure to do that and also click the bell because I only
make a video about once or twice a week.
So you don't want to miss the ones that do upload in all your other subscriptions.
Now, if you guys want to keep watching the next video I'd recommend is how you might
be actually using your monitor wrong.
And I know I was until I discovered this.
So you can check that out.
It's probably going to be a bit mind blowing, so you can
just click on that right there.
So thanks so much for watching guys, and I'll see you in the next one.