Downloading blank file when trying to access to the website using http

[gnoirzox]

Hi,

I have deployed my project at http://cityhacke.rs and I am having this issue with some browsers (especially with Chrome on Android), it will download a blank file and not return the index page.

In my log file, the error returned is the following: "TLS handshake error from : tls: first record does not look like a TLS handshake"

Did you encounter this issue before? It seems to be related either to the fragmenta/server package or autocert.

[kennygrant]

You're trying to serve an http request with tls, which won't work. The server attempts to redirect to root_url, so probably this is down to not having a root_url key set? I think I didn't put this key into the bootstrap when it makes a new secrets file but should. Put a key like this in your secrets/fragmenta.json

"root_url": "https://cityhacke.rs",

This should mean the redirect here in server.go works. I'm planning adjusting things to make it more friendly for setting up new sites run off this, at present it was released more as an example of code for golangnews rather than an adaptable news site.

[gnoirzox]

Unfortunately, I still getting the same error. The root_url was previously set to

"root_url": "https://cityhacke.rs:443",

So I removed the the port number, but I am still getting a blank file to download on android and it will not redirect me to the https url.

I am using go 1.8.3, do you it could come from this version?

[kennygrant]

Hmm, not sure. So the actual problem is your http request is being served with https. This means you don't have an http server running. However when I visit that site no http I don't see that, I get a binary download instead (https works fine).

Re go version, it seems unlikely but could be possible I guess that I'm relying on something in 1.9.

Does your server.go match exactly the file on github presently?

[gnoirzox]

Yes, it seems that the redirection doesn't work and it wants to serve the tls handshake over the http connection.

I have updated to the latest version; but, unfortunately, the issue keeps happening.

That's really weird because my server.go seems to match yours.

[kennygrant]

Make sure also you have the latest version of the server library:

go get -u github.com/fragmenta/server  

Verify that you definitely have the right secrets file on the server, you are using the right config version, and you have the right keys in the config being loaded.

I'd then try inserting a fmt.Printf at around line 40 with the keys: autocert_domains, autocert_email and root_url and make sure that all those keys are being set correctly in the running version.

You should also be able to test locally if you disable the check on Production() and set up a redirect. You'll get cert errors of course when serving https but you could test the http redirect works as you expect.

[gnoirzox]

I did the update of the server dependency and also inserted the Println and it displayed the expected parameters.

I also tested the redirect on my local dev environment and, unfortunately, it did not work either.

But, after investigating a bit more on my production server, it appears that the redirection works on ipv6 (at least for me) but it doesn’t when the port 80 is hit with ipv4. As the port 443 is accessible from both ipv6 and ipv4. It seems to me that the redirection is at fault here but I have no clue why it doesn’t work on ipv4...

On 17 Oct 2017, at 01:03, Kenny Grant notifications@github.com wrote:

Make sure also you have the latest version of the server library:

go get -u github.com/fragmenta/server
Verify that you definitely have the right secrets file on the server, you are using the right config version, and you have the right keys in the config being loaded.

I'd then try inserting a fmt.Printf at around line 40 with the keys: autocert_domains, autocert_email and root_url and make sure that all those keys are being set correctly in the running version.

You should also be able to test locally if you disable the check on Production() and set up a redirect. You'll get cert errors of course when serving https but you could test the http redirect works as you expect.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kennygrant/gohackernews/issues/32#issuecomment-337078437, or mute the thread https://github.com/notifications/unsubscribe-auth/AAt-_AjzwiYJC1bULUCPfq8RRroeDaOJks5ss-7vgaJpZM4P5kcZ.

[kennygrant]

Oh interesting. My next step would be to try isolating this by producing a small go test case separately, using the code from RedirectAll, to see if a standalone little go server example has the same problem. I haven’t been able to see this here. If you have code I can try running I can take a look on my end.

[gnoirzox]

Actually, the issue was coming from my firewall frontend (firewalld) which for some reason was blocking the port 80 even if I configured it to accept the http protocol. I decided to use iptables and ip6tables and it works fine on both ipv4 and ipv6.

My apologies for bothering you as my issue was not related to the project itself but due to the configuration of my environment.

[kennygrant]

Glad you got it sorted. Thanks for closing.