pico adds :80 to the end of all my URLs, which breaks SSL

[Swizzler121]

title explains what is happening. Clicking on a link results in SSL cert error: Secure Connection Failed with the exact error being: SSL_ERROR_RX_RECORD_TOO_LONG

manually removing :80 from the URL line or removing https fixes the issue.

Manually setting the URL in the config didn't change anything and anyway I don't want to manually set the URL because there are several urls (.org/.com etc) my site is linked to.

I have no plugins installed, using the latest version of pico (not the betas)

[PhrozenByte]

This is due to a misconfiguration of your webserver. Your webserver provides Pico with contradictory environmental information, making it virtually impossible to properly determine the base URL automatically. Check your webserver config, especially the environment variables passed to PHP, namely the SERVER_PORT and HTTPS environment variables (other related environment variables are shown here). Otherwise you'll have to configure the base URL manually or write a plugin to properly resolve the conflicting environment variables.

[bjarneds]

I have a similar problem on a site that I manage. I therefore wrote to my hosting provider about the webserver misconfiguration, referring to this issue. However, their response is that this is expected behaviour, caused by the fact that Apache is behind Varnish, and thus not directly exposed.

Since I'm, using Pico CMS, they suggested as a workaround that I specify base_url in the config.yml file. I have tried this (setting it to https://mysite), and it does seem to work. There is however one problem "under the hood": When looking at the network tab in the browsers DevTools window, I can see that if I'm accessing the site via http (not https), it now uses https instead of http to request the parts needed for the page. This is fine for the most parts, but there are a number of CORS errors when requesting parts like https://mysite/themes/default/font/DroidSansMono-Regular.woff2?1516549146. It doesn't seem to have any visual effect on the page (maybe I'm not using these parts), but I still do not like it. Of course, I could make a .htaccess file to force access via https, but for the time being I'm leaning towards not doing this.

Also, I feel that my hosting provider do have a point in their argument and that it is wrong to rely on SERVER_PORT for this use. Is this something you will consider to change in Pico CMS? Or do you have another workaround that doesn't cause problems for http?

[PhrozenByte]

By manually configuring a base_url you completely bypass Pico's base URL guessing, thus it won't have any effect here. If you don't want to force HTTPS (you should force it!), simply leave the protocol in the base_url config (see https://en.wikipedia.org/wiki/URL#prurl).

[bjarneds]

Thanks. I didn't know about PRLs - that does solve this problem (and I think I would prefer this, even if I do end up forcing HTTPS). One minor problem though: The site currently supports URLs both with and without www prefix. This means if I configure base_url to //mysite and go to www.mysite, I get the same CORS errors mentioned (and likewise, if I configure base_url to //www.mysite, I get CORS errors if I go to mysite. Any ideas to work around that?

[PhrozenByte]

You could write a plugin for that. But no, not out-of-the-box.

[mayamcdougall]

@bjarneds, A little late here, but personally I just avoid dealing with "www." prefixed requests altogether, by redirecting them to their non-www equivalent in my web server config. This isn't actually something I do for CORS reasons, I've just always been against most of my domains having a pesky, optional "www." in front of them. 😂

Not sure if that's relevant to your use case or not, but since I prefer not to have the "www" in my urls, it ends up being an easy way to "support" them (in case someone happened to add a "www"), while not actually having to worry about them.

If someone visits www.example.com/some-page-url, it just redirects them to example.com/some-page-url instead (and, with a 301 permanent redirect, so it should stay cached in their browser too).

Anyway, just thought I'd chime in, in case that wasn't something you'd thought of before. 😉

[bjarneds]

@mayamcdougall I appreciate your input - I actually decided to redirect non-www to www (and http to https).

There seem to be SEO arguments for using a canonical url (either with or without www). The majority leave the choice to a matter of taste, but a few - e.g. https://www.bjornjohansen.com/www-or-not - argues for www due to reasons that mostly apply to large sites.

Re, redirecting http to https: Maybe I'm missing something, but I can't really see a reason to force this on my site (no login, input of data from user or similar), but there seem to be consensus that you should always do it, so I decided to just follow along.

This means I could solve the problem by configuring the base_url as suggested, but I decided to make a general fix by writing a simple plugin.

[mayamcdougall]

The majority leave the choice to a matter of taste, but a few... argue for www due to reasons that mostly apply to large sites

Huh, that's an interesting read. Actually didn't know about the cookie behavior either. I've never done anything big enough that choosing non-www would cause a problem. When I made the decision years ago, it was definitely only for the aesthetics of it.

Hmm, I guess I didn't actually say it in my comment before, but I did mean to imply that you should go with whichever redirect (www or non-www) suited you best. 😅

So I'm glad that worked out for you. 😁

Maybe I'm missing something, but I can't really see a reason to force this

I think the general mentality is just to make privacy the default on the web going forward. Even if there's nothing that needs to be secured, using encryption still prevents packet eavesdropping and man-in-the-middle type situations. Not that you specifically need this, but just the idea that it should just be everyone's default mentality going forward. Security first, even when it doesn't matter, that way you'll be more protected when it does.