Do links with commas work?

[Rοb]

Without reading every post in this thread (apologies, I am just about to go out), the best way to tackle this is to parse the comma within the URL unless it is the last character.

If someone types an URL followed immediately by a comma and then more text (without spaces), they really need to go back to school. No amount of code/regex is going to help them.

Sorry if this has already been mentioned, but I feel it is the best solution.

[Robulosity2]

Simple solution.. Use BBCode if you / your users want to "parse" Hyperlinks with URL.. works fine, takes an extra 2 seconds.

Beyond that?

Teach your users to use TinyURL or something like it.

[T3XT3]

What about this?

I searched http://www.google.com/#hl=en&q=test,but it didn't work

What about it? That's false orthography. A space belongs after a comma. Really don't see the problem: There are MANY links with commas. And fewer people, which can't do correct punctuation...

Simple solution.. Use BBCode if you / your users want to "parse" Hyperlinks with URL.. works fine, takes an extra 2 seconds.

Well, you could turn off the whole URL parsing engine with this argument... so it's pretty useless. Commas are a valid constituent of hyperlinks! That we even have to put up a fight to integrate that in the engine is outright absurd.

[Wolfie]

How about just installing Clippy..

[bfarber]

What about it? That's false orthography. A space belongs after a comma. Really don't see the problem: There are MANY links with commas. And fewer people, which can't do correct punctuation...

You give people on the internet a lot of credit. ;) Sure, it's not valid punctuation usage. "R U Happy" isn't either, and I see this all the time online. Or "Win". That's not a sentence, but that doesn't stop people from posting it as a sentence.

Perhaps we'll revisit this in a future update, but really it's not high priority. Either way, some users can't have what they want. Automatic parsing isn't magic, and it's difficult to account for every scenario.

[.Ian]

Maybe some people are querying it, as commas in URL's are not broken in VB and some of the posters on this forum have converted from VB ;)

[T3XT3]

You give people on the internet a lot of credit. ;) Sure, it's not valid punctuation usage. "R U Happy" isn't either, and I see this all the time online. Or "Win". That's not a sentence, but that doesn't stop people from posting it as a sentence.

Perhaps we'll revisit this in a future update, but really it's not high priority. Either way, some users can't have what they want. Automatic parsing isn't magic, and it's difficult to account for every scenario.

I just wanted to stress the following: You as software developers have to balance two needs. There is (a) the urge to breach the orthography (but that said: people, who use commas in the WWW communication, usually know that it is followed by a space). And there is (b) the expectation of the users, that the parsing engine will catch most of the URLs. That you have decided against need(b) & for need(a) [url=" the first place is unintelligible. Maybe this is not top priorty, but it is a problem of usage convenience. I mean, it is pretty bold to justify the non-parsing of billions of potential links with the notion that bad spellers exist... need(b) is always to favor!

And believe me: A pretty big German news magazine, whose articles are often exchanged, is using commas in their links. That's a pain in the *** for mods to always correct when users overlook the non-parsing. (And many DO overlook!) Ask them about priority...

[bfarber]

the first place[/url] is unintelligible. Maybe this is not top priorty, but it is a problem of usage convenience. I mean, it is pretty bold to justify the non-parsing of billions of potential links with the notion that bad spellers exist... need(b) is always to favor!

And believe me: A pretty big [url="http://www.spiegel.de/"]German news magazine[/url], whose articles are often exchanged, is using commas in their links. That's a pain in the *** for mods to always correct when users overlook the non-parsing. (And many DO overlook!) Ask them about priority...

I'm not discounting your viewpoint at all. But for this to be a "big issue" nearly a year after release also speaks for the urgency of changing such functionality. :) A bug report or two has cropped up, but overall this hasn't been a big issue for the lifetime of 3.0 (until now, if you would call it a "big issue" now).

[Brandon D]

I'm not discounting your viewpoint at all. But for this to be a "big issue" nearly a year after release also speaks for the urgency of changing such functionality. :) A bug report or two has cropped up, but overall this hasn't been a big issue for the lifetime of 3.0 (until now, if you would call it a "big issue" now).

Commas in URLs worked in 3.0.0 and 3.0.1 -- it wasn't until 3.0.2 that it was "fixed" the way it is now:
http://community.invisionpower.com/index.php?app=tracker&showissue=17233&hl=comma
You even mentioned in the bug report the solution that seems to be the consensus here -- parsing commas in a link up until a space is found, exclusive of a preceding comma.

Since 3.0.2, a quick tracker search shows at least five bug reports (and I'm sure a handful of topics like these) on it, even one from a staff member who handles support tickets. Better yet, do a quick search in the P2P forums and take a look.

I guess I don't see how you can mark some of your "Unintended User Behavior" reports as such and yet cripple the parser in order to "fix" this unintended user behavior issue.

[T3XT3]

I'm not discounting your viewpoint at all. But for this to be a "big issue" nearly a year after release also speaks for the urgency of changing such functionality. :) A bug report or two has cropped up, but overall this hasn't been a big issue for the lifetime of 3.0 (until now, if you would call it a "big issue" now).

That depends on the aspects you deem appropriate for the bigness of the issue, doesn't it? When it is the quantity of complaints, go with it. When it is the quality of the arguments, you put up a shallow justification (as I have already said in my first bug report here). When the "auto URL detector is designed to parse *most* URLs" (as Matt has mentioned), then I don't understand, why so many links are dismissed. And to justify this with the allusion of the orthographic oafishness of the users of IPB! "Working as intended" - nice phrase, if the intentions are illogical! :D

Commas in URLs worked in 3.0.0 and 3.0.1 -- it wasn't until 3.0.2 that it was "fixed" the way it is now:

You even mentioned in the bug report the solution that seems to be the consensus here -- parsing commas in a link until a space is found.

Having read this a few months ago, I was pretty flabbergasted about this preposterous "consensus" - and shocked about the unreasonable reasoning!

[.Ian]

the first place[/url] is unintelligible. Maybe this is not top priorty, but it is a problem of usage convenience. I mean, it is pretty bold to justify the non-parsing of billions of potential links with the notion that bad spellers exist... need(b) is always to favor!

And believe me: A pretty big [url="http://www.spiegel.de/"]German news magazine[/url], whose articles are often exchanged, is using commas in their links. That's a pain in the *** for mods to always correct when users overlook the non-parsing. (And many DO overlook!) Ask them about priority...

Seems newspapers are the most common users of this style.

I'm not discounting your viewpoint at all. But for this to be a "big issue" nearly a year after release also speaks for the urgency of changing such functionality. :) A bug report or two has cropped up, but overall this hasn't been a big issue for the lifetime of 3.0 (until now, if you would call it a "big issue" now).

8 months since it was 'fixed', not nearly a year ;) - and to be fair the majority of us making this point have not been using the product for that long, and there have been quite a few tickets raised on the error, not one or two. So trying to say users have ignored it for nearly a year is inaccurate and not fair to your customers.

If a product has a failing then surely it does not matter if it is 6 months or 6 years.

I also wonder whether the fault was created in http://community.invisionpower.com/index.php?&app=tracker&showissue=17233&view=findpost&p=66465 when you said 'How exactly is IPB to know the comma isn't part of the URL?' - which seems the opposite of what you are saying now???

Mind you when the tickets are closed as 'working as intended' and Matt says 'We're happy with how it works' - it does not give users much hope in getting a fix to what for them is a major issue.

You also said in another ticket 'The comma is meant to be a punctuation mark for the sentence, not a part of the URL' - this is not true.

Anyway it is clear that it will not be fixed any time soon, and whatever we say will be trivialised and twisted so there is little point in continuing to put our case.

[.Ian]

Apologies - I broke my post for dinner, so posted and did not see the other two replies which between them have said what I have said.

Maybe a good example of a need for the ajax quick reply ;)

[Luke]

What difference does it make if Google includes un-encoded commas in their url's? They are usually wrapped into link tags. The point I'm making is that in regard to auto detecting a URL in a paragraph a comma is technically not a valid character in a URL. Does that mean that we shouldn't add some logic to include commas where it makes sense? No. I'm just pointing out what is technically correct. It may not be the same as user intent or what the user deems as logical.

Now we can all agree that spaces do not belong in the URL, and thus is a breaking character. We could say that a comma is a breaking character only if it is the last character (as you have suggested). What if I had a URL like this, for the sake of argument:

http://domain.com/script.php?var1=value1&delim=,

In this case the comma is the last character, but the comma was supposed to be part of the URL. But using your suggestion it isn't. So you would have to add "if a the comma comes after an = sign it is part of the URL".

I'm sure there are other variations where a comma is last but should still be part of the URL (ignoring that it should be encoded properly). But this is an example of what bfarber was trying to point out about it not being as easy as you think.

[.Ian]

Sadly what you believe to be correct is false. Unless of course you can show me some some official documents that commas cannot be in URI's and that Google and countless of other sites including several newspapers are totally wrong. :)

A quick question - if it is wrong, why did IPB previously parse commas correctly (as Brandon pointed out above) and why does VB parse them properly?

[Nimdock]

I agree commas should be parsed. People copy and paste links all the time without using the link BBCode and/or button. Google maps links are always broken in my forum because of this.

[Luke]

Sadly what you believe to be correct is false. Unless of course you can show me some some official documents that commas cannot be in URI's and that Google and countless of other sites including several newspapers are totally wrong. :)

A quick question - if it is wrong, why did IPB previously parse commas correctly (as Brandon pointed out above) and why does VB parse them properly?

I'll correct what I said: It's only valid in the file name if the operating system allows it, but is invalid in the query string. Every example provided thus far shows the comma in the query string, which is why I generalized.

Here is an online tool that uses the url encoding mechanism:

http://www.opinionat...ode/Encode.aspx

Put the comma in the first box and hit "Encode". Any character that converts into %## is a character that cannot should not be into a query string.

I'm not arguing what VB does, what IPB did, or what IPB does now. I'm just saying that a comma is not valid in the query string un-encoded. I'm also saying that there's a little more to it than saying "only include the comma if it isn't the last character" because some URL's could be considered valid, even if it was the last character. Please understand that I'm not for or against either side. I'm just stating plainly that a comma isn't valid in a query string, and as bfarber tried to point out: it's harder than you think.

[.Ian]

Please feel free to provide links to documentation to backup your claims, that it is invalid in the query string :)

[Brandon D]

RFC 1738 actually states commas may be used within the URL unencoded, but that is besides the point. Whether it's "proper" or not is irrelevant -- it's used commonly enough to be a pain when it isn't automatically parsed by IPB.

[T3XT3]

I'll correct what I said: It's only valid in the file name if the operating system allows it, but is invalid in the query string. Every example provided thus far shows the comma in the query string, which is why I generalized.

EEEH! Wrong.

Mind you when the tickets are closed as 'working as intended' and Matt says 'We're happy with how it works' - it does not give users much hope in getting a fix to what for them is a major issue.

I would speak of a helpless feeling of futileness that the stuff is forcing on one. :(

[bfarber]

RFC 1738 actually states commas may be used within the URL unencoded, but that is besides the point. Whether it's "proper" or not is irrelevant -- it's used commonly enough to be a pain when it isn't automatically parsed by IPB.

--Removed--

(Post was previously quoting the RFC, but I missed the comma character in the string)

[Luke]

RFC 1738 talks about the URL in general (i.e /filename.html). RFC 3986 talks about the query string, which is where the comma is being used in the examples in this topic relate to. I'm not sure if 3986 says exactly regarding commas, but I'm sure it isn't a character that can be used because of how the function urlencode works in PHP. The function rawurlencode references RFC 1738 in the description, which it's true that urlencode isn't just limited to the query string. But urlencode also takes into account 3986 because urlencode is also used for properly escaping values in a query string.

Regardless of who's right in wrong, and what is or isn't in the spec: There are situations where a comma can be at the end of a URL. So saying that a comma is always in the middle of a URL is an incorrect assupmption. Trying to fit every situation is more difficult than you realize, especially if the comma isn't valid according to RFC 3986.

[Luke]

Would like to correct the above: I meant 2396 not 2386. Typo..

[Robulosity2]

Well, you could turn off the whole URL parsing engine with this argument... so it's pretty useless. Commas are a valid constituent of hyperlinks! That we even have to put up a fight to integrate that in the engine is outright absurd.

That has to be the worst argument I've heard in the long run.. You may as well just say "I'm being a lazy tard.. kthnx"

It's a valid solution, so use it or stop complaining

I rarely agree with Wolfie but I'm going to have to say, his post (the one that followed mine) suits this topic perfectly..

[Brandon D]

You do realize Wolfie's post was a pun against those who have your position, right? ;)

I don't know why we're arguing whether comma's are accepted in URLs, query strings, or what ever part of the URL you feel like choosing. It doesn't matter. They're still used. Hence this thread.

[Wolfie]

You do realize Wolfie's post was a pun against those who have your position, right? ;)

It was? I was being quite serious about parsing commas unless it's the last character. It's not a perfect solution, but it would seem to be the best.

Or do you mean the Clippy one? That was to say that no matter what solution is found, there will ALWAYS be an exception that makes someone think that it's broken.