97

Links written with the first character as a capital, e.g.

Http://stackoverflow.com

do not appear in a post, although they are shown in the preview. Here is a link that becomes invisible after submitting the post:

13
  • 19
    Http://comments.are.unaffected.example.com
    – Compass
    Commented Dec 12, 2014 at 21:35
  • It also happens in part of the domain if you read the information presented you'll see that its a bigger issue than just the scheme.
    – Jay
    Commented Dec 12, 2014 at 21:44
  • 1
    Are protocols actually case-sensitive ? I'm pretty sure they aren't (just like hostnames) in which case "Http" should just be converted to "http" on submission.
    – user2629998
    Commented Dec 13, 2014 at 0:28
  • 1
    The scheme isn't and the domain shouldn't be however the path can be interpreted with case sensitivity so that should be left alone obviously.
    – Jay
    Commented Dec 13, 2014 at 0:30
  • 1
    Since it is invisible, wouldn't it be possible to hide spam this way? If so I would see it as a problem.
    – bummi
    Commented Dec 13, 2014 at 0:51
  • 1
    @bummi Since it's "invisible" I don't see how it could be a problem. "to hide spam this way" Hidden spam is not really a big problem.
    – James
    Commented Dec 13, 2014 at 1:58
  • 1
    @James I was thinking about Google e.g., not sure what can be used for link popularity, since preview and content seem to be scanned. My knowledge here is poor, it was an apprehension.
    – bummi
    Commented Dec 13, 2014 at 2:04
  • @bummi But where does Google get "invisible" and "hidden" links from? At worst there may be something in the edit history. Although, Spam is dealt with quite strictly, so it would be removed, along with the user. And all links are no-follow anyway. I could be wrong, I just don't know of a scenario where this would be an issue.
    – James
    Commented Dec 13, 2014 at 2:11
  • 2
    @bummi Google can't see these "invisible" links in posts, because if you actually look at the HTML, you'll see they aren't even there. It's not that they're present but hidden, they just aren't generated in the HTML output for the post.
    – Jason C
    Commented Dec 13, 2014 at 15:31
  • 1
    About the spam, even though it's not visible in the html, if the googlebot can follow links (and yes, it can) it can also find the spam under the edit link. So, there you have it.
    – Mr Lister
    Commented Dec 13, 2014 at 17:56
  • 8
    Turns out that you can't use this to circumvent the minimum length restriction on the main site. i.sstatic.net/n9jq6.png Commented Dec 13, 2014 at 21:15
  • Well then that's a positive thing!
    – Jay
    Commented Dec 13, 2014 at 21:22
  • 1
    data query to help find such potential invisible links: data.stackexchange.com/stackoverflow/query/722474/…
    – Cœur
    Commented Sep 13, 2017 at 14:35

5 Answers 5

72

Nice finding that bug.

For proof that it really is a bug, refer to RFC 3986, section 3.1 Scheme:

Although schemes are case- insensitive, the canonical form is lowercase and documents that specify schemes must do so with lowercase letters. An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" as well as "http") for the sake of robustness but should only produce lowercase scheme names for consistency.

The comment-handling seems to work right.

10
  • 3
    When all else fails refer to the request for comments :-D
    – Jay
    Commented Dec 13, 2014 at 13:29
  • 1
    That doesn't necessarily mean it's a "bug" here. If the way it is currently handled is how it was decided to be handled, then it is status-bydesign. Of course, that's not saying the "design" shouldn't be changed.
    – James
    Commented Dec 13, 2014 at 14:07
  • 8
    @James: why would this be "by design"? It being a straight-out bug is far more likely, per Hanlon's Razor.
    – Jongware
    Commented Dec 13, 2014 at 14:30
  • @Jongware I don't know, I don't have access to the site's back end code or previous dev discussions and decisions. That's why I said "doesn't necessarily" and "If the way it is currently handled..."
    – James
    Commented Dec 13, 2014 at 14:44
  • 26
    @James "I've got an idea," said one of the developers. "What if capitalized URLs, instead of being treated as either links or plain-text, were made ENTIRELY INVISIBLE instead?" "Okay," said the other developers. "We hereby intend that to be how things should work."
    – Sneftel
    Commented Dec 14, 2014 at 10:27
  • @Sneftel Your sarcasm is based on speculation. You do not know whether that scenario is real or not, you just think it's not because it is the less likely one. "Less likely" is not conclusive.
    – James
    Commented Dec 14, 2014 at 14:45
  • 1
    @Sneftel James is correct. You're speculating. Commented Dec 15, 2014 at 2:20
  • 8
    @james Sufficiently less likely is conclusive, as no evidence is sufficient to make any claim more than sufficiently less likely. Developers posting with exact statements is not conclusive: they could have hallucinated. Sneftel's argument is robust: the design of "make them invisible" is pretty ridiculous. As a guess (and this is a guess, not conclusive), they have a "check URLs for attacks, and if we don't read the URL as clean, we hide it", and the code for the check doesn't admit the possibility of MiXeD CaSe HtTp. Commented Dec 15, 2014 at 3:16
  • 1
    StackExchange markdown seems to break unexpectedly with URLs in posts quite often, then work perfectly well in comments...
    – Izkata
    Commented Dec 15, 2014 at 17:15
  • @Yakk "The design of 'make them invisible' is pretty ridiculous" Is it? So, how they should have handled it? And presuming they "did not want them to be seen"...
    – James
    Commented Dec 15, 2014 at 18:31
41

I tested this in the MSE Formatting Sandbox first, but now that I can replicate it, it looks like any capital letter in the protocol section of a link created by specifying a bare URL in Markdown results in this behavior - disappearance of the link.

Here's a copy of what I tested, in case the sandbox answer is changed/updated.


Testing normal:

http://stackoverflow.com

http://stackoverflow.com


Testing Http

Http://stackoverflow.com


Testing Https

Https://stackoverflow.com


Testing Ftp

Ftp://example.com


Testing a nonexistent protocol

DoesNotExist://example.com

DoesNotExist://example.com


Testing ALL CAPS:

HTTP://example.com


Testing rEVERSE cAPITALIZATION:

hTTP://www.example.com


Testing capital only in Domain:

http://Www.example.com

http://Www.example.com

3
  • 9
    Good find! Even more of a reason to fix
    – Jay
    Commented Dec 12, 2014 at 20:50
  • 3
    "DoesNotExist://example.com" +1 for thinking on that Commented Dec 14, 2014 at 20:47
  • You can get the preview right (i.e. with some links invisible) if you put your link between HTML brackets < and >.
    – Cœur
    Commented Sep 13, 2017 at 14:46
8

There are two highly upvoted answers here that state "yes it is a bug" and a couple of downvoted ones that say "don't fix it".

I would like to offer this answer in favor of the "let's fix it" camp - and maybe to get a taly. We will see from the up/down votes what the community thinks. Consider this intended as a counterpoint to answers that say "don't fix it".

When someone includes a link in their answer that would be valid if copy/pasted into the address bar of their browser, it is reasonable to assume they intend it to be used as a link. While I understand that the current "link validator" may trip over the capitalization, I would like to see a change to the engine that allows the link - whether formatted with a [text](Http://link) or directly as a Http://link. It would be a very simple matter to return the protocol string as all lower case - no harder than rendering it invisible, for instance.

I see three possible approaches.

  1. Do nothing
  2. Render every valid link as typed
  3. Fix formatting of unconventionally cApItalized protocol strings

If you believe the current behavior is preferable, please downvote my answer. If you want either (2) or (3), indicate so by upvoting. A simple comment "prefer option 2" or "prefer option 3" would help (and that's exactly 15 characters...)

I don't buy the argument that "allowing unconventional capitalization will bring down the quality of the site". We have plenty of keen editors who will fix the occasionally mistyped protocol. My preference is for option 3 (but I can't upvote my own answer :-) )

7
  • 2
    prefer option 3
    – Floris
    Commented Dec 15, 2014 at 16:27
  • 1
    I'd like to point out that my answer is not saying "don't fix it" exactly. I support making the text visible. I am only against altering the link-rendering code to allow Http as a link. This is an added feature that I think should not be built.
    – user2555451
    Commented Dec 15, 2014 at 16:43
  • 2
    That said, I think it would be great if SE is willing to have the protocols be auto-lowercased. It would fix all of the problems and save editors the time of correcting unconventional URLs. +1
    – user2555451
    Commented Dec 15, 2014 at 16:51
  • Definitely agree it needs to be fixed.
    – Jay
    Commented Dec 15, 2014 at 17:28
  • I never said don't fix it, anywhere, once, not even suggested it...
    – James
    Commented Dec 15, 2014 at 17:50
  • @James - you did say that it was not a simple fix, and that effort was not worth it for the infrequent occurrence: "Not for such a small issue with likely a tiny occurrence..". I may have read more into that statement than you intended, and I apologize for misrepresenting you.
    – Floris
    Commented Dec 15, 2014 at 17:59
  • I said "So these would be new systems, and not really a simple resolve to this bug" And that was specifically in context of Jay's suggestion of all sorts of new system requirements, such as auto correct and scripts checking specifically for http etc. Again, I agree something should be done, just what should be done is the big question. And I stand by no-one knowing whether this is a bug or not other than devs, as per my new answer (FWIW). No need for apology, we're all just chewin' the fat ;)
    – James
    Commented Dec 15, 2014 at 18:04
-1

In response to comments, and now an answer in response to my saying not to fix it.
I have said throughout that I don't disagree it "could" be a bug, just that only the developers can confirm this.
I also agreed somewhere that non lowercase http simply not rendering is not practical or ideal at all.

My entire point has been this:

The general consensus seems to be "This shouldn't be like this therefore it's a bug". And as it's allowed in the RFC Stack not allowing it is therefore a bug.

A bug is not "something which doesn't work how we believe it should work".
That's just something which could be "improved", including allowing mixed case http because the RFC states it's permissible.

A bug is specifically "something which doesn't work how it was intended to work".
If a script for users to login doesn't allow users to login, there is a bug.

Users arguing "devs would not just allow non lowercase http to not render" have not worked in a crazy/busy dev pit, "things" sometimes happen like this.

Perhaps it is a bug, and the devs shrugged their shoulders because it doesn't harm anything. Perhaps they already have it on a loooong todo list to sort one day.

Only they know their intentions etc.



To allow mixed case or not

It can be argued that because an RFC states mixed case http is allowed, then a site such as Stack should allow it, given it's significant presence on the internet for technology based discussions etc.

However, I don't agree we should just because RFC states it's allowed.
I also see a good argument that Stack should set an example in having continuity in content, such as only allowing lower case http, and not having messy looking hTtp and other variants.

Profanities are a valid part of the English language, but they have no place on Stack.
Why ever not - they are in the dictionary, so therefore Stack should allow them.

No, Stack decides that even though profanities are a valid part of the language, it's offensive so they don't allow it.
Just as mixed case http is in the RFC, but it's messy and looks poor.

We can make choices, and not allowing mixed case http doesn't mean we're stating it is not correct, just the same as we're not stating profanities are not a part of the dictionary.
We're just making choices as to what we want to see on our site.

http is acceptable, and looks better than mixed case, so why not enforce all lowercase to be clean looking?

[Please don't argue that it's entirely different because profanities are offensive whereas mixed case http is not. Of course that's true, but the entire point is both are valid yet we can choose not to allow them.]

What should be done about it

So, discussion on the main issue here, and that is currently users text disappears without warning or notification, which is not fair and is quite confusing.

I do agree that non lowercase http simply not rendering is not a good scenario. Users will wonder where their link went to, they might not even notice it.
And of course it could be the main part of the question or answer, and so they receive downvotes as a result of the Q or A being poor etc.

However, would you really be happy for posts around the site to look like this:
HTtp://stackoverflow.com
hTtP://stackoverflow.com
htTP://stackoverflow.com
+ others

Or, only ever allow:
http://stackoverflow.com

Personally, I think the mixed case ones look stupid, and Stack should promote clean looking URLs and have continuity throughout the site, not just conform to some RFC.

However, we do need to do something other than pretend the mixed case http didn't exist.


So, I think the best solution would be for non lowercase http to be automatically put in quoted text block.
Then the link is still there, users can see it's there but not rendering, and can edit the post to fix it.

Then we don't see HtTp in the site as genuine links, which looks stupid and ugly.

2
  • 3
    Clear and sensible answer.
    – Floris
    Commented Dec 15, 2014 at 18:13
  • 2
    And that is one of my main concerns. The moment we allow Http:... as a link is the moment when all other (ugly) forms start slipping in simply because they "work in the browser". There is something to be said for respecting consistency and convention. Thanks for giving some examples of how bad bad can get.
    – user2555451
    Commented Dec 15, 2014 at 18:34
-10

TL;DR: We should make the text visible, but it should not be a link. Instead, it should be plain text.


Apparently, the community feels very strongly that this is an issue worth fixing. My original answer said that it wasn't much of a problem and that we should ignore the behavior for the sake of having correctly formed URLs in posts. But after ~20 downvotes and a hoard of negative comments, I am willing to retract that opinion for the sake of the community.

However, I--and I'm sure quite a few others--still strongly believe that we should not treat Http: as if it were a properly formed protocol. It is simply incorrect by convention and accepting it will only encourage people to use the incorrect form in posts. Also, it opens the door for all other variations of the protocol such as HTTP:, hTTp:, etc. While this is not horrible, it still brings down the quality of the posts on our site (and makes us look like we don't know what a protocol is ;)

Therefore, I offer a compromise: we should change the behavior so that the text is visible in the post, but we should not make it a valid link. Instead, it should be rendered as plain text.

In defense of this proposal, I have four points to make:

  1. I refer you to @rgettman's answer and how DoesNotExist://example.com renders as plain text in the post. Just as DoesNotExist: is not treated as valid protocol, so Http: should be likewise ignored.

  2. By making the Http: text visible, we stop people from including hidden spam in posts as well as circumventing the character limit for posts (@MartinSmith's answer is a prime example of this last point). At the same time, by not making it a valid link, we encourage users to edit Http: to the correct http: form so that their links work as intended.

  3. This proposal does not interfere with the author's intent in any way by auto-correcting the links. Instead, it posts exactly what the author types. And if they want it to be a real link, all they need to do is edit H to h, which takes little more than a second.

  4. I've said this before, but we cannot allow Http: as a valid protocol because then hTTp: and all other incorrect forms should likewise be allowed by the same logic. And then, why not also allow people to omit the http: altogether and just post www.site.com or even just site.com?. As you can see, there is really no end to this. If we make more than one valid way to render links, then we will soon have dozens of ways to render links.

    Limiting users to just one correct form keeps things consistent and easy to manage.

As for comments allowing Http:, I do not think that that is a valid argument because comments are 2nd-class citizens. You can't really compare them with questions and answers. Just because comments allow incorrectly formed URLs does not mean we should transfer this behavior to the important posts. Also, typing comments is a very rapid action, which means typos are natural in comments. Questions and answers though should be written with care and quality.

In summary, I see this as being the best of both worlds. We eliminate all the problems with the invisible text as well as prevent people from using Http: as if it were correct.

21
  • Great now your half way there, just a little more and we're good. You still don't seem to understand that no matter which case I type it in the functionality should not change. Maybe if my text wasn't turned into a link automatically then this would not be an issue. Since its changed it needs to be changed correctly.
    – Jay
    Commented Dec 13, 2014 at 20:08
  • 1
    Eh, that's as far as I can go. I can't accept Http: as a correctly written protocol. It is simply incorrect. And I don't see why the site should have to compensate for people thinking it is correct. Making the text visible is fine, but treating Http:... as equal to http:... is a design flaw. A bug if you will. ;) It does not make the site more intuitive or user-friendly. Instead, it trashes convention, allows ugly and incorrect URLs, and makes the code for rendering links all the more complex since we now have to account for every possible variation of every possible protocol.
    – user2555451
    Commented Dec 13, 2014 at 20:50
  • 4
    You would have to account for all forms. Allowing Http: but not say HTTP: is arbitrary. Why is one incorrect form acceptable but not the other incorrect form? But I respect your opinion. Besides, it's not like you or I have any say over what happens anyways since only the SE devs themselves can make the final decision. We'll just have to wait and see. In the meantime, have a nice holiday season. :)
    – user2555451
    Commented Dec 13, 2014 at 21:09
  • Again limited thinking on how to handle it. Right on. Thanks. U too.
    – Jay
    Commented Dec 13, 2014 at 21:24
  • 2
    @iCodez At least you're thinking logically and with an open mind. Discussions should remain civil and all those involved should consider others' opinions with the potential of having one's mind changed, or just learning a new perspective. Not just beat down those who disagree, and upvote and grin with those who do agree. Sigh...
    – James
    Commented Dec 14, 2014 at 2:06
  • @James - I agree. Sadly however, it seems that we are really outvoted in this. The community's will is case-insensitive protocols, so that will probably be put into effect despite our arguments against it. Oh well, we tried. So much for following convention. :)
    – user2555451
    Commented Dec 14, 2014 at 2:23
  • 1
    Not necessarily, it's up to Stack at the end of the day, whether they feel it's worthwhile, and should be done. There are many posts with hundreds and some thousands of up votes on MSE, yet nothing is done. I'm not against change, or improvement, as long as the proposed change is decent. And I disagree that just allowing all kinds of mixed case within http is acceptable, and nor do I care what any RFC states. I've yet to see any feasible solution - even Jay deleted his answer with a proposed idea...
    – James
    Commented Dec 14, 2014 at 2:25
  • 1
    The protocol scheme is case-insensitive, so they should work Commented Dec 15, 2014 at 11:31
  • But Http is a correctly formed protocol! The site has plenty of editors willing to fix typos when they are them - but the can't see the invisible link. I don't buy the argument that allowing legal links would bring down the quality of SE. There are more important things to worry about.
    – Floris
    Commented Dec 15, 2014 at 12:50
  • @Floris - Http is correct in the same sense that hTTp is. Meaning, they will work if you happen to type them into a browser (browsers are often smart enough to lowercase it for you), but they are still incorrectly formed by convention. I'd be fine if SO was willing to auto-lowercase Http like browsers do, but that interferes with the author's post too much. So, I am against allowing Http as a link for the sake of having proper URLs.
    – user2555451
    Commented Dec 15, 2014 at 15:55
  • @Floris - Otherwise, we'll have practically anything be a URL. I mean, you are fine with Http:... but what about hTTp:... or HTTp: or even no protocol (www.site.com as I said in my post). Do you see what I mean? We cannot allow just Http and ignore all other forms because that is arbitrary. If we allow one, we will sooner or later allow them all.
    – user2555451
    Commented Dec 15, 2014 at 15:57
  • 1
    @iCodez - my suggestion is to allow "anything that is a valid link". I would argue that while you can omit http:// in many address bars, that doesn't make it a valid link; but a server will respond correctly to the request hTtP://.... I argue that "if it is valid, allow it". If it bothers you that this is "ugly", then the simple tweak to take the (valid) protocol string and render it as all lower case would be a very simple piece of code. But I believe the current status is a bug, not a feature. That's just an opinion, not a fact.
    – Floris
    Commented Dec 15, 2014 at 16:02
  • 1
    @IsmaelMiguel - How do you come to that conclusion after reading my answer? I'm curious because others have said the same thing. I do support fixing the visibility bug. My whole answer supports it. I am only against making Http a link.
    – user2555451
    Commented Dec 15, 2014 at 17:16
  • 1
    @IsmaelMiguel - I said: "Therefore, I offer a compromise: we should change the behavior so that the text is visible in the post, but we should not make it a valid link. Instead, it should be rendered as plain text." I want the Http text to be plain text and not a link.
    – user2555451
    Commented Dec 15, 2014 at 17:20
  • 2
    @IsmaelMiguel - There, I put it right at the top. Geez, I hope that that is not the reason why I got all these downvotes, because people couldn't find my point. :/ Thanks for bringing that issue up.
    – user2555451
    Commented Dec 15, 2014 at 17:44

You must log in to answer this question.

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