client/Command() has nothing to do with links, because links aren't commands. They're not actually sent to the server at all when activated, rather they simply cause a reaction client-side.

If you wanted to define links in command() for some other purpose than to view that link, it is currently impossible.

There's no reason you would want to use links in Command() because of the aforementioned explanations of what links are supposed to do and how they are not commands.
If you wanted to do something related to a URL of some sort and have it for some reason intercepted server-side as an argument, you could simply format the URL as a command instead of as a link. Better yet, you could format it as an argument to a verb instead of most likely improperly resorting to using Command().

Could this be changed?

No need for it to be, neither would a change like this make a lot of sense.

Chowder wrote:

I think it should be handled server side simply because it wouldn't be very hard to do.

You know, "it's not hard to do" is not a reason to do something. When you possess a personal gun, killing pedestrians is very easy, but that's not a reason to do it (note: this analogy is in regard to real-life, not GTA).

Also, I really shouldn't need to explain this more than I already have, but here goes: making links suddenly be handled server-side will only accomplish adding to the network bandwidth. It does not add any new worthwhile ability, and it does not make sense to be added to client/Command(), one reason for that being: this procedure is for processing commands, and links are not commands or being treated as commands. If Dream Seeker gets a request to execute command beginning in a protocol designator (http://, byond://), it entirely skips sending it to the server as a command.

And because its a little misleading for it not to be called.

A little, sure, until you understand that links aren't being treated as commands (which should be about time now ;P ).

Although you could work around it by setting the input box to a verb it wouldn't go well with what I think Mista-mage123 is doing.

I don't know what he's doing, but from what he's said and the impression he's given, it seems he is most definitely going about it wrong by making this feature request instead of doing what he wants to do the right way.
What is he trying to do?

Do you mean calling link() with basically a value you chose in the code, or...?
Otherwise, that would have made no sense (so perhaps that's why they altered it, if they have). Why would you even link() a link the player just submitted if that would've caused the player to open it anyway? Or, are you saying that, what, back then, in projects that have overridden client/Command(), Dream Seeker didn't activate the link itself?

Mobius Evalon wrote:

If input controls do that automagically now, it must be a very recent feature.

They do, which feels only natural.
Then, apparently, initially all non-client-side commands were sent to the server, but after they added this feature the command bar began to catch HTTP URLs and so they were also identified as non-commands and not sent to the server anymore, as there's no need for that.
Doubt this change is very recent, tho. For what it's worth, I can't remember it ever not being this way (but I guess it's possible I forgot).

Don't think so. If there was, you'd find it in the Skin Reference, anyway. But it was probably like this from before 4.0 and there is no parameter to change this behavior because, well, it's not needed. I still haven't heard what you guys want this feature for and why it can't be done without it. I don't see much worthwhile new options it would bring.

It could be worthwhile to include a parameter in input controls to make them always dump anything typed in them to the server as commands to enable that sort of thing, but as I've said previously, this is nothing you can't do already; if you want to do something with a URL, but not have it be interpreted as a link, then don't form the command text as a link, so it's an actual command. You can enter the URL without the http:// prefix, in which case it would be interpreted as a command, or you can make the command text begin with something other than the URL (you can just include a character in front of it), so it's not interpreted as a URL - preferably passing the URL as an argument to a verb. You can implicitly attach a prefix to all commands executed by an input control by setting its default command, as Chowder suggested, which would look like what you had intended to do.