Internal topic link behavior on non-http installs


#1

We’ve noticed that linking a topic by using the full url e.g. http://domain.com/t/topic-slug/1234 vs the relative url /t/topic-slug/123 result in different behaviors on our site.

Linking the full url (http://domain.com/t/topic-slug/1234) will cause the whole page to reload (and clicks don’t get counted), whereas the relative url (/t/topic-slug/123) will refresh the ember outlet without having to refresh the entire page.


Posted Internal Link Not Loading Dynamically
(Jeff Atwood) #2

Hmm is this something we can fix @eviltrout?


(Robin Ward) #3

I just tested this locally and couldn’t reproduce it. Are you talking about creating links within a post using markdown? Are they on their one line (oneboxed) or embedded within text?


#4

They’re markdown’ed like this:

[Link to topic A][1]
[Link to topic B][2]

[1]: http://my.domain.com/t/slug/123
[2]: /t/slug/222

(Rafael dos Santos Silva) #5

Yeah this happens with me too, found it while linking the FAQ to the about page with a full link.


(Robin Ward) #6

I just used the same markup in my test environment and it didn’t force a full refresh. Here’s an example on meta:

Link to topic A
Link to topic B


#7

That’s weird. I was able to reproduce it on my local vmware copy of discourse (both copies are non-https).

Another thing I noticed is that the the full link will work if you click on the link after you post a link or edit the post, but will do a full page once you come back. :confused:


#8

I think I may have figured out what is causing this issue…

Looking at the page source, I noticed that the full links causing a full page refresh were cooked like this:
<a href="//domain.com/t/slug/123/1">topic a</a>
whereas the ones that would work (such as the ones in the gutter) included the http: prefix:
<a href="http://domain.com/t/slug/123/1">topic a</a>

Your link above seems to include the https: prefix, and thus works as expected.


Posted Internal Link Not Loading Dynamically
(Jeff Atwood) #9

How are you getting unprefixed links, though? Manually entering them?


#10

I have no idea. The link has the http:// prefix when I submit a new post/link, but it then get removed when I come back to that post.

edit - it’s missing the http prefix in the api json, so it’s not a browser issue…


(Jeff Atwood) #11

Describe, step by step, the buttons or keys or touchscreen presses you made to create the post with the problem? I am not following.


#12

It doesn’t really seem to matter how we do it, internal links just seem to have their http prefix removed once ‘cooked’:


(Sam Saffron) #13

Can you repro this on http://try.discourse.org/ ? Its a non HTTPS site, we only do the // hack on non HTTPS sites.


#14

Seems to be working as it should with the full url…


(Kane York) #15

This is probably an oddity around using an IP address… what happens if you assign that IP address the name discourse.internal and tell Discourse that that’s its hostname?


#16

Same issue with a real domain - that’s where we actually noticed the issue and were able to reproduce it on a vmware install (w/ip address). I can try to assign a name to the vmware and see if it still has the bug.

I believe @falco also has the same issue on a live site.


EDIT:
Ok looks like it has nothing to do with the domain/ip address, just rebuilt my container with DISCOURSE_HOSTNAME: ‘discourse.vm’ and it does the same thing:


(Kane York) #17

Do not use discourse.vm, because IANA/ICANN/whatever might decide to make .vm a TLD at some point. How about discourse-vm.internal or discourse.vm.local?


#18

Rebuild the container with discourse.local as the hostname, no plugins, v1.4.0.beta7 +76.
Still missing the http on the cooked posts:

"cooked": "<p><a href=\"//discourse.local\">Domain Link A</a><br><a href=\"//discourse.local/t/test-link/280/2\">Domain Link B</a><br><a href=\"http://192.168.10.122/t/test-link/280/2\">IP Link</a> <br><a href=\"http://google.com\">External Link</a> </p>",

(Jeff Atwood) #19

I guess if we can’t repro the behavior, it is something specific to your install…


#20

I guess could always just write a script to add the missing http to the cooked version, but it does seem to be a bug since I was able to reproduce it on a live digital ocean install and a local vmware install.

Is there a setting to disable this?