-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trouble with links when both HTTP and HTTPS versions of site available #157
Comments
If you could just add documentation to the doc site about running with https and instruct people to use the config.yaml approach. |
The proposed solution is not working in master... - Local server is now: |
This is related to issue #622 because one solution would solve both issues. Specifically, if all the internal links (from page to page, from tags to page, from page to css and js and all other assets) are done using relative links only, then
I envisage that Hugo would need to track It's worth doing and I might be able to help do some of the work if we can divide it into smaller pieces. |
Temporary workaround for the bug fix and resulting behavioral change in purell.NormalizeURLString(): a leading '/' was inadvertently to relative links, but no longer, see gohugoio#878. I think the real solution is to allow Hugo to make relative URL with relative path, e.g. "../../post/hello-again/", as wished by users in issues #157, #622, etc., without forcing relative URLs to begin with '/'. Once the fixes are in, let's remove this kludge and restore SanitizeUrl() to the way it was. Fixes gohugoio#878
Temporary workaround for the bug fix and resulting behavioral change in purell.NormalizeURLString(): a leading '/' was inadvertently to relative links, but no longer, see #878. I think the real solution is to allow Hugo to make relative URL with relative path, e.g. "../../post/hello-again/", as wished by users in issues #157, #622, etc., without forcing relative URLs to begin with '/'. Once the fixes are in, let's remove this kludge and restore SanitizeUrl() to the way it was. Fixes #878
Setting `RelativeURLs` to `true` will make all relative URLs in the site *really* relative. And will do so with speed. So: In `/post/myblogpost.html`: `/mycss.css` becomes `../mycss.css` The same in `/index.html` will become: `./mycss.css` etc. Note that absolute URLs will not be touched (either external resources, or URLs constructed with `BaseURL`). The speediness is about the same as before: ``` benchmark old ns/op new ns/op delta BenchmarkAbsURL 17462 18164 +4.02% BenchmarkAbsURLSrcset 18842 19632 +4.19% BenchmarkXMLAbsURLSrcset 18643 19313 +3.59% BenchmarkXMLAbsURL 9283 9656 +4.02% benchmark old allocs new allocs delta BenchmarkAbsURL 24 28 +16.67% BenchmarkAbsURLSrcset 29 32 +10.34% BenchmarkXMLAbsURLSrcset 27 30 +11.11% BenchmarkXMLAbsURL 12 14 +16.67% benchmark old bytes new bytes delta BenchmarkAbsURL 3154 3404 +7.93% BenchmarkAbsURLSrcset 2376 2573 +8.29% BenchmarkXMLAbsURLSrcset 2569 2763 +7.55% BenchmarkXMLAbsURL 1888 1998 +5.83% ``` Fixes gohugoio#1104 Fixes gohugoio#622 Fixes gohugoio#937 Fixes #157
Temporary workaround for the bug fix and resulting behavioral change in purell.NormalizeURLString(): a leading '/' was inadvertently to relative links, but no longer, see gohugoio#878. I think the real solution is to allow Hugo to make relative URL with relative path, e.g. "../../post/hello-again/", as wished by users in issues gohugoio#157, gohugoio#622, etc., without forcing relative URLs to begin with '/'. Once the fixes are in, let's remove this kludge and restore SanitizeUrl() to the way it was. Fixes gohugoio#878
Setting `RelativeURLs` to `true` will make all relative URLs in the site *really* relative. And will do so with speed. So: In `/post/myblogpost.html`: `/mycss.css` becomes `../mycss.css` The same in `/index.html` will become: `./mycss.css` etc. Note that absolute URLs will not be touched (either external resources, or URLs constructed with `BaseURL`). The speediness is about the same as before: ``` benchmark old ns/op new ns/op delta BenchmarkAbsURL 17462 18164 +4.02% BenchmarkAbsURLSrcset 18842 19632 +4.19% BenchmarkXMLAbsURLSrcset 18643 19313 +3.59% BenchmarkXMLAbsURL 9283 9656 +4.02% benchmark old allocs new allocs delta BenchmarkAbsURL 24 28 +16.67% BenchmarkAbsURLSrcset 29 32 +10.34% BenchmarkXMLAbsURLSrcset 27 30 +11.11% BenchmarkXMLAbsURL 12 14 +16.67% benchmark old bytes new bytes delta BenchmarkAbsURL 3154 3404 +7.93% BenchmarkAbsURLSrcset 2376 2573 +8.29% BenchmarkXMLAbsURLSrcset 2569 2763 +7.55% BenchmarkXMLAbsURL 1888 1998 +5.83% ``` Fixes gohugoio#1104 Fixes gohugoio#622 Fixes gohugoio#937 Fixes gohugoio#157
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Hi guys, first off Hugo is an amazing piece of software. Thanks so much for all the effort put into it.
Having one issue, though, when a HTTPS version of a site is available. The baseurl as set in config.yaml is rendered (perhaps) a bit too literally. I'm imaging many users will set it to something like "http://yoursite.example.com/" as is shown in the documentation.
If a site is using https, though, that breaks things in a browser, with an unsafe mixture of content. This only seems to occur with any
<script>
tags, not with<a>
tags,<link>
tags, etc. They all seem to be handled properly.Why not just strip the http: or https: prefix from the baseurl, or at least encourage using a //www.example.com in the configuration. (FWIW, dropping the http: prefix in config.yaml works, but many may not know to do that.)
If this is something that's worth doing, I can probably submit a PR if desired, but wanted to talk it over first. Perhaps it's a non-issue, too, since the solution is so easy via the config file and very few blogs are actually going to have a valid certificate.
The text was updated successfully, but these errors were encountered: