mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2012
Posts: 19
K
krypto Offline OP
Pikka bird
OP Offline
Pikka bird
K
Joined: Jan 2012
Posts: 19
It seems that mIRC v7.25 can't handle weblinks containing [ or ] characters in URLs. It cuts the rest of the URL after that. They work correctly in v6.35.

So URL
http://www.website.country/something?whatever[code]&something_else[more_codes]

becomes

http://www.website.country/something?whatever

EDIT: Even these forums can't handle those grin

Last edited by krypto; 30/08/12 06:10 PM.
Joined: Jul 2006
Posts: 3,961
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,961
The [] character shouldn't appear in an url as plain text, they should be encoded and mirc is now probably (and correctly) following that rule.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Jan 2012
Posts: 19
K
krypto Offline OP
Pikka bird
OP Offline
Pikka bird
K
Joined: Jan 2012
Posts: 19
What do you mean by that? If someone types an URL in a channel window, users shouldn't double click on that URL but instead open up the URL catcher window and then use the URL that appears there instead? I don't use that, because it's redundant. Did you actually check if this happens? It's very easy to do, you can just do an echo and then click on the link and see where it takes you.


EDIT: Even the URL catcher doesn't do it correctly. It handles the first [ fine, but when the closing ] comes, the URL stops there. So it works a bit better than what you get in a channel window, but it's still horribly broken.

so you get eg.

http://www.website.country/something?whatever[code

and that's it.

EDIT2: And it's plaintext, no encoding done on the links. Would probably be a quick fix to add encoding on url catcher, but it should be fixed PROPERLY so it works in the channel window LIKE IT SHOULD.

EDIT3: I bet this comes down to the same thing that causes this:
http://forums.mirc.com/ubbthreads.php/topics/238501/UTF_8_decoding_encoding#Post238501

Could you please stop pretending that the client isn't broken and just fix what's clearly broken? Nicknames not showing up on the nickname list isn't a bug and people should auto-kick users or ban them because mIRC can't handle them? Is that REALLY what you're suggesting as a fix? You can't pretend that nothing is broken forever.

Last edited by krypto; 30/08/12 08:39 PM.
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
Calm down.

Wims was trying to explain that [] characters are technically not allowed in URLs and instead should be 'encoded' (i.e., escaped) as described here: http://www.blooberry.com/indexdot/html/topics/urlencoding.htm . He's not talking about codepages or UTF encoding at all. I think his point was just to explain this might have been the rationale behind how it works now.

That said, since some web browsers let you use those characters in URLs anyway, it might be worth looking into.

The fact that the URL catcher does not behave the same way as hotlinks is probably a bug. It's a bit much to call it "horribly broken" though.

I'm going to disregard the codepage discussion since it's not related, but if you really want to discuss it, keep in mind it's pretty much already been rehashed many times before.

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
As mentioned, [] is not supposed to be in a real URL anyhow without being escaped/encoded. Other characters are also escaped in URLs, such as spaces. If you use the correctly escaped link, then you won't have a problem. If someone types it without correctly escaping it, then sure, mIRC will probably not handle it correctly. That really isn't a bug, but more of just simply not handling a situation that shouldn't need to be handled. It is the same as links that have spaces in them. If someone types them without escaping the spaces, the full link won't be clickable. That isn't a bug by any means. Properly escaped, [code] should look like: %5Bcode%5D . That being said, unless there is some specific reason not to handle it, then mIRC could be changed to handle URLs that are not properly escaped (other than ones with spaces).

As far as your code page comments that aren't related to this discussion, anyone who wants to maintain support for outdated encoding can easily use mIRC 6.35. Everyone else who wants to stop living in the past can use newer versions that support an encoding that lets all languages talk together at once without changing encoding all of the time. There is no reason new versions of mIRC have to maintain backwards compatibility with outdated things like code pages. Unicode has been around for a long time and if people haven't started using it by now, they have no one to blame but themselves.


Invision Support
#Invision on irc.irchighway.net
Joined: Jan 2012
Posts: 19
K
krypto Offline OP
Pikka bird
OP Offline
Pikka bird
K
Joined: Jan 2012
Posts: 19
I would say that ALL modern web browsers let you use those characters in URLs. Also, by "horribly broken", I'm referring to the whole [] issue, not just the URL catcher.

EDIT: Regardless or not if those characters should be in an elitist "real url" as stated in some ISO standard (made almost 10 years ago when the Internet was new), they're still there in the real world (TODAY!) and mIRC should deal with that properly. If you have a problem with that, then write to Mozilla, Microsoft, Google and Apple so that their web browsers would be compatible with mIRC's URL handling.

EDIT2: This is going to that "mIRC is perfect, everyone else is wrong" -discussion again as I already stated. Please, stop pretending that mIRC is perfect.

EDIT3: Also the issue, Riamus2, isn't about the codepages or wanting support for those. It's the fact that some nicknames don't display on the nicklist AT ALL because they use some character that the SERVER ALLOWS THEM TO USE IN THEIR NICKNAME. That is clearly the fault of the IRC client (in this case mIRC) if it can't display those users on the list at all. I won't go into that here, I just used it as an example on how nothing gets done when people pretend that nothing is wrong.

Last edited by krypto; 30/08/12 09:50 PM.
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Browsers don't technically support it. They just let you type it. It's still converted before it's used. IE even converts it immediately so you can see it instead of doing it in the background. And the browsers are only displaying it a certain way. The servers where the sites are hosted require valid names. It isn't elitist just because you don't like it. The real URL is what is sent to the server to access a page/site/etc. And that URL is escaped regardless of how you type it in a browser or how the browser displays it. mIRC also gives you full control over hotlinking and you can create a hotlink script that will handle non-standard URLs if you need it. But as I said, if there's no specific reason not to allow support for it, then mIRC could choose to provide that support. But it certainly isn't a bug.

Regarding code pages, there have been numerous threads on it and it has been clearly stated multiple times that new versions of mIRC are not going to be backwards compatible with outdated code pages. mIRC 6.35 is available for anyone who needs it. It doesn't matter if the problem with using new versions of mIRC on a network that still allows code pages is missing nicks in a nick list or "corrupted" text when someone's talking or anything else. The simple fact is that mIRC does not support it and will not. That isn't a bug and it isn't changing. mIRC offers the older version if you need support for it and that's the most you'll get. If you really want support in new versions of mIRC, write a DLL that can provide the support.

Btw, no one ever claimed mIRC was perfect, so that's a completely irrelevant argument.


Invision Support
#Invision on irc.irchighway.net
Joined: Jan 2012
Posts: 19
K
krypto Offline OP
Pikka bird
OP Offline
Pikka bird
K
Joined: Jan 2012
Posts: 19
Originally Posted By: Riamus2
It isn't elitist just because you don't like it.
That was pointed towards mIRC's way of handling URLs. It clearly expects the URLs to be perfect and according to ISO standards. When in the real world, they can be either encoded or user friendly. Most of the time, they're user friendly, because most people don't see %20 between words or any other weird symbols. If they do, I suggest seeking immediate medical help.
Originally Posted By: Riamus2
The simple fact is that mIRC does not support it and will not. That isn't a bug and it isn't changing.
Originally Posted By: Riamus2
Btw, no one ever claimed mIRC was perfect, so that's a completely irrelevant argument.
By not fixing a bug or refusing to fix it, that bug becomes a feature. Thus, mIRC is free of bugs. This URL handling bug seems to be going to same road and is soon a feature. Completely irrelevant. I also like that users need to create the bugfi... sorry, anti-features on their own or seek help from other users to share these anti-features in forms of dlls or scripts to make the client perform correc... sorry again, customize the client to their needs.


EDIT:
Just as a reminder:
Word: Perfect
Definition: Being without defect or blemish.

Claiming mIRC has no bugs and only features is the same as claiming it is perfect.

Last edited by krypto; 30/08/12 10:11 PM.
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
krypto, we are not developers for mIRC. There is only one person who is (Khaled). Unless he is the one who says it, it's not an official stance taken by mIRC's author. We are just stating our opinions on how we feel it ought to work, just as you have.

By the way, in case you haven't realized, we have all agreed with you that mIRC should accept [] in URLs. We are only explaining that things like this are not always so simple or clear cut.

Dropping codepage support is not a bug. Khaled deliberately removed it from mIRC in 7.x, and even made a fairly detailed post here explaining why. You may not agree with the change, but calling it a bug doesn't really help your cause, which I presume is to persuade Khaled to re-add support for codepages.

Last edited by drum; 30/08/12 10:29 PM.
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
No one said there weren't any bugs either. They stated that removal of code pages is not a bug. You can't use an argument based on words taken out of context because it will fall flat.

There is nothing wrong with moving forward and dropping support for outdated items. If every application supported every outdated thing just because a relatively small number of people want it, nothing would improve. Just because it's something you feel you need doesn't make it wrong to remove it. Unicode is the current standard and is used worldwide and has been used for a very long time. I'm sorry you don't like that fact, but that's simply the truth. No one has to make something to "fix" this because it doesn't need fixed and because if they really need the outdated functionality, older versions are available that work just fine.


Invision Support
#Invision on irc.irchighway.net
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
OK, issue reported. There's really nothing else to be said here, let's just sit quietly and see if it's changed in the next version.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Sep 2003
Posts: 36
K
Ameglian cow
Offline
Ameglian cow
K
Joined: Sep 2003
Posts: 36
I'm surprised not one person here has bothered to quote original and subsequent RFCs to justify the situation. Am I the only one here who reads RFCs? :-) Let's delve into those. Please read EVERYTHING I have written before responding -- because the final conclusion (opinion) may be different than what you think I'm eluding to in my earlier paragraphs.

First and foremost there was RFC 1738, which states clearly:

Quote:
... Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters. These characters are "{", "}", "|", "\", "^", "~", "[", "]", and "`".

All unsafe characters must always be encoded within a URL. ...


Encoded means turned into their percentage-encoded equivalents. For example, [ needs to become %5b (0x5b hexadecimal), ] needs to become %5d (0x5d hexadecimal), and so on. The list of unsafe characters MUST be encoded: it isn't optional, it's MANDATORY. But let's continue.

Secondly, RFC 3986 expands on this fact. This is outlined clearly on Wikipedia as well. You can read the Wikipedia article sections on unsafe characters to see for yousrelf.

Now let's talk about RFC 2732 and RFC 3513 (both which are older than RFC 3986, I'll point out) -- which introduces IPv6 support into URLs. Bracket characters (e.g. [ and ]) are permitted in a URL, but only within the FQDN/address area ("URI syntax"). Such an example URL would be:

http://[1080::8:800:200c:417a]/foo

This fact is also covered within RFC 3986. Pay very, very close attention to the last line:

Quote:
A host identified by an Internet Protocol literal address, version 6 [RFC3513] or later, is distinguished by enclosing the IP literal within square brackets ("[" and "]").

This is the only place where square bracket characters are allowed in the URI syntax.


Now here is a very important point:

Web browsers such as Firefox, Chrome, etc. permit you to enter URLs like http://foobar.com/blah[ilikerice] because behind the scenes they are actually turning this into http://foobar.com/blah%5bilikerice%5d. They don't show you this in the URL bar, but they're doing it behind the scenes; thus, from your perspective, they let you violate RFC. But if you were to look at the actual HTTP GET or POST requests (using Wireshark or Firebug) you would see them encoded. Some browsers (Firefox for example) even let you enter spaces into the URL field -- and it turns them into %20 (like it should) when sending them to the server.

If users on IRC (that includes bots/etc.) are not complying with RFC standards, that's their own fault -- they should be. If IRC servers which generate URLs themselves (internally) and spit them out non-encoded, that is ALSO their fault. Shame on both.

...but what should mIRC itself be doing, since all it technically does is launch a browser instance with a provided URL/string?

mIRC should actually be passing the URL string to the browser literally. So truly, if a user puts in http://foobar.com/blah[ilikerice] then mIRC should pass http://foobar.com/blah[ilikerice] to the browser.

As it stands right now (mIRC 7.25), mIRC appears to terminate the passed string early, e.g. http://foobar.com/blah[ilikerice] gets passed to the browser as http://foobar.com/blah -- and that is indeed an mIRC bug, if you ask me. mIRC should simply let the browser's URL and URI parser decide what to do with the encoding of the string passed to it. The end-of-URL delimiter should be either space (literal ASCII space or the Unicode-equivalent) or end-of-string. Pretty simple, and less overall work for Khaled if you ask me. :-)

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
It's not that we don't read RFCs, it's that your RFCs mean nothing in this context.

The RFC's don't have to deal with delimiters on URL boundaries-- the RFC can get away with specifying all characters allowed in a URL because it's assumed the entire input is the URL.

This is not the case on IRC. On IRC, Messages (rightly) contain informal formatting and input where URLs may or may not be separated by whitespace boundaries. In many cases, URLs end with NON-whitespace boundaries. There is no way around this, and it's completely unreasonable to claim that it is a "user's fault" for not doing this.

Let me break your example with a quick and easy counter:

Instead of writing http://example.com/blah[FOO], someone on IRC writes "Generating status [20req/s for http://example.com/blah]"

Note the "]" at the end of the URL. It is clear to any human that ] is not part of the URL. There are many equivalent cases with {}, |, etc.-- mIRC should separate URLs by punctuation, because punctuation *should* delimit a URL in the context of an IRC conversation. Even a "." or "," at the end of a URL should not be considered part of the link, even though those characters are allowed as per the RFC. It's therefore just NOT possible for mIRC to pass a URL verbatim to the ending whitespace.

I should point out that it would be possible for mIRC to improve heuristics for [] and only delimit URLs when they are found at the end of the input (like . works now), but that still only give you "http://example.com/foo[FOO", omitting the final ]. You could theoretically scan for opening and closing parentheses, but it wouldn't be a reliable check.

FYI, even this forum behaves in the same way. If you could guarantee formal delimitation for the beginning and end of the URL, you could pass it in verbatim. If you're detecting the boundaries based on heuristics, you can't.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"

Link Copied to Clipboard