1

By "SEO part of the URL" I mean:

stackoverflow.com/questions/question_id/this-is-the-seo-part

The SEO part appears to be constructed where for each character in the question's title:

  • If it's a letter or a number, copy it in the SEO part
  • If it's not and the last character in the SEO part is not a dash, add a dash

This, however, has the big problem that questions with C++ in the title appear to a human reader to be about C.

Example: C++, an "impossible" behavior , whose title is "C++, an “impossible” behavior."

My proposal

Consider plusses as valid characters. You don't even have to replace them with %XX, C++, an "impossible" behavior is a perfectly valid URL.


Note
I know that some of you don't like it when people put the language in the question title, but whether you like it or not it's something that is done in practice. So I feel that what I proposed is necessary, and I also ask you to please not discuss here about whether putting the language in the title is good practice or not. Thanks.


Edit
There has been some discussion about whether + is a valid character in an URL, and whether it has a valid meaning. In a path it is valid and it doesn't have a special meaning.

From the RFC:

  reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                "$" | ","

In 3.3. Path Component:

  pchar         = unreserved | escaped |
                  ":" | "@" | "&" | "=" | "+" | "$" | ","

The path may consist of a sequence of path segments separated by a
single slash "/" character. Within a path segment, the characters "/", ";", "=", and "?" are reserved.

So, pchar (the valid characters in a path) is formed by unreserved characters in addition to the reserved characters explicitly allowed.

8
  • Same is true of C#, though there well be other reasons why the "#" isn't included.
    – ChrisF Mod
    Jan 30 '10 at 22:17
  • 1
    @ChrisF: yes, C# is impossible to "fix", unless you replace '#' with 'sharp', which isn't such a bad idea. Anyways, one thing at a time, if this gets accepted we can propose to fix # too. Jan 30 '10 at 22:23
  • 2
    It appears you don't understand what a + actually means in the URL.
    – random
    Jan 31 '10 at 1:49
  • @random: does it matter what it means? Please explain what practical disadvantages there would be if you misuse it. Jan 31 '10 at 1:58
  • @random: you still alive? =p (PS: do note that according to RFC 2396 that link is perfectly valid) Jan 31 '10 at 13:38
  • 3
    Keep reading where it says "used as delimiters". Stop reading halfway.
    – random
    Jan 31 '10 at 13:57
  • @random: there is a difference between invalid and misused. As I stated above "Please explain what practical disadvantages there would be if you misuse it". You still haven't answered. For whether it's valid or not, it is valid. I'll make you an example so it's really super simple: <table>s for layout are valid but misused. The HTML validates, but you are misusing them. The same would be true in this case: the URL is valid, but you are misusing the plusses. Again, please explain why this is so wrong. Using my old example, SO does use tables for layout. Jan 31 '10 at 14:11
  • 2
    @random: + absolutely is a valid character for a path part — see the production for pchar in the same RFC. Just because some characters are generally “reserved” as potentially having special meaning in URLs, that doesn't mean they're unusable in all parts of a URL. You have to check the grammar for the specific part you're interested in to find out.
    – bobince
    Jan 31 '10 at 21:34
1

You can't have plus in the URL, so it would need to be encoded, like so:

C++, an "impossible" behavior

pound also has to be encoded:

C++, an "impossible" behavior

In conclusion: meh.

15
  • 1
    ?? No.. As I already said in my post, + is a valid character and doesn't have to be escaped. The very HTML of my post contains <a href="http://stackoverflow.com/questions/1793678/c++-an-impossible-behavior">. EDIT: oh, saw John Smithers' post. I don't think it really matters though. Jan 31 '10 at 0:13
  • 2
    @Koper a space character is translated into + by some browsers (I know that IE does this for sure.)
    – Hogan
    Jan 31 '10 at 1:43
  • 1
    @Hogan: and where is the problem with that? First of all they are not spaces but they are already +'s, so they are not transformed by any browser. Second, that part of the URL is useless, even if an imaginary browser transforms the +'s in something else it would work anyway. Jan 31 '10 at 1:54
  • @Koper: Is the point of this to help SEO? If so then a search engine would just turn the + into a space -- it would have no effect on the search. Thus, what is the point?
    – Hogan
    Jan 31 '10 at 7:26
  • @Hogan: no, the point is to not confuse the people reading it. For example when I paste the question's url in IRC channels, etc. People then think it's a question about C and not C++. Jan 31 '10 at 7:35
  • 3
    @koper I don't think you understand the issue fully Jan 31 '10 at 16:22
  • 4
    A space character in a path is not converted into a plus. That type of encoding is only for form submissions in query parameters. + is an absolutely valid character to include, unescaped, meaning itself, in a URL path.
    – bobince
    Jan 31 '10 at 21:31
  • 1
    @Jeff, can you explain it further then? After further examination of part 3.3 of the RFC pointed by @bobince and @sth, I read it clearly says that a plus is a valid character, without special meaning in the path part of the URL. It only has a special meaning after a ?, such as in /test?abc=a+b Feb 1 '10 at 13:43
  • @koper we prefer to keep our URLs free of any characters that aren't a-z or dash -- so they are always detected as URLs everywhere in the world. Including an unencoded plus will break something, somewhere. Not worth it. Feb 1 '10 at 20:38
  • 1
    I see. How against would you be replacing '+' with the word 'plus' and '#' with the word 'sharp'? Just throwing the idea out there. So it would become c-plus-plus-an-impossible-behavior, i-like-programming-in-c-sharp. It won't help nor hurt SEO, but they are more user friendly. Feb 2 '10 at 3:33
  • @Koper, I like that idea (of course taken to the extreme might drive @jeff bonkers, as everyone demands context sensitive translation of punctuation for their language or sub-system).
    – Hogan
    Feb 3 '10 at 1:57
  • @Hogan: I'm not aware of any context where '+' is not pronounced plus.. Feb 3 '10 at 2:29
  • @Koper: Cute. As I'm sure you know I was talking about the having to translate != as not equal, <> as not equal, .not. as not equal, /= as not equal, ~= as not equal etc etc there are a lot of languages on SO and they all their punctuation characters have specific translations, there may be some language that treat one of those character sequences above as some other meaning thus you would need context sensitive translation.
    – Hogan
    Feb 3 '10 at 3:06
  • 1
    @Hogan: well, I didn't want to take this that far. != should remain "invisible". My main concern is not confusing C with C++ and C#.. I don't want to "translate" every possible symbol in every possible language. Translating != is much less important because it doesn't cause any confusing in titles. Feb 3 '10 at 3:15
  • @Koper: Sure, however the problem is SO is open to so many people with so many agendas, you can't just add a feature for C type language and ignore everything else; many users would be upset (not that I would, but that is the problem with this type of feature.)
    – Hogan
    Feb 4 '10 at 17:06
1

Some freaks out there think, that your URL is not perfectly valid:

2.2. Reserved Characters

Many URI include components consisting of or delimited by, certain special characters. These characters are called "reserved", since their usage within the URI component is limited to their reserved purpose. If the data for a URI component would conflict with the reserved purpose, then the conflicting data must be escaped before forming the URI.

 reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                "$" | ","

The "reserved" syntax class above refers to those characters that are allowed within a URI, but which may not be allowed within a particular component of the generic URI syntax; they are used as delimiters of the components described in Section 3.

2
  • 1
    I don't think it really matters. This is when standards get in the way.. For example, the HTML of stackoverflow is very far from being standards complaint, if that's ok I don't see why using +'s only for the "intended purpose" is important. Jan 31 '10 at 1:57
  • 4
    According to "3.3. Path Component" of the RFC you linked, "+" is a valid character in this place of an URI.
    – sth
    Jan 31 '10 at 6:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .