Skip to content
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

https support? #22

Closed
zeehio opened this issue Mar 21, 2016 · 10 comments
Closed

https support? #22

zeehio opened this issue Mar 21, 2016 · 10 comments

Comments

@zeehio
Copy link

@zeehio zeehio commented Mar 21, 2016

Hi,

Given the LetsEncrypt initiative, by which it is easy to obtain a valid and free SSL certificate accepted in most major browsers, would it be possible to have https://cranlogs.r-pkg.org/ ?

For https websites having access to https badges would be great.

Thank you for your work and sorry to disturb you.

@gaborcsardi
Copy link
Member

@gaborcsardi gaborcsardi commented Jun 27, 2016

Yes, sorry. In a minute....

@gaborcsardi
Copy link
Member

@gaborcsardi gaborcsardi commented Jun 27, 2016

Ok, it is HTTPS now. Thanks for the suggestion.

@gaborcsardi
Copy link
Member

@gaborcsardi gaborcsardi commented Jun 27, 2016

Actually, I had to revert this, because the HTTP -> HTTPS redirect killed all badges.

@gaborcsardi gaborcsardi reopened this Jun 27, 2016
@zeehio
Copy link
Author

@zeehio zeehio commented Jun 30, 2016

Why not offering both http and https? (Maybe I am missing the obvious)

@gaborcsardi
Copy link
Member

@gaborcsardi gaborcsardi commented Jun 30, 2016

I don't know how to support that form dokku. dokku supports an HTTP -> HTTPS redirect, but that killed all current badges.

@zeehio
Copy link
Author

@zeehio zeehio commented Jun 30, 2016

I don't know much about dokku, although here it says how to redirect (301) all http to https.

Using 301 redirects with images should not be a problem according to this stackoverflow answer.

Sorry to cause you this trouble... having a site working both with http and https is a relatively normal situation, I did not expect it would be difficult to set it up.

I have a similar setup in my nginx configuration:

# Redirection:
server {
   listen 80;
   listen [::]:80;
   server_name my_server_name.com;
   rewrite ^ https://my_server_name.com$request_uri? permanent;
}

# Actual web being served
server {
  listen 443;
  listen [::]:443;
  server_name my_server_name.com;
  root /where/to/serve/stuff/from;
  ...
}

Feel free to leave this issue if you can't find a proper way to fix this. I wish I could provide more detailed information 😅

@gaborcsardi
Copy link
Member

@gaborcsardi gaborcsardi commented Jun 30, 2016

It is easy to redirect, it is even easier than that. As soon as you add the credentials, dokku redirects automatically.

I actually did it already, and it broke all badges on GitHub. So I need to figure out a way not to redirect, but serve both HTTP and HTTPS. Which seems to be harder with dokku.

@zeehio
Copy link
Author

@zeehio zeehio commented Jul 1, 2016

shields.io does not have a problem redirecting http to https:

In this log we see that shields.io does use image redirection (see the 301 Moved Permantently) when I download an image:

$ LANG=C wget http://img.shields.io/travis/rust-lang/rust.svg?maxAge=2592000
--2016-07-01 10:17:01--  http://img.shields.io/travis/rust-lang/rust.svg?maxAge=2592000
Resolving img.shields.io (img.shields.io)... 104.18.44.160, 104.18.45.160
Connecting to img.shields.io (img.shields.io)|104.18.44.160|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://img.shields.io/travis/rust-lang/rust.svg?maxAge=2592000 [following]
--2016-07-01 10:17:01--  https://img.shields.io/travis/rust-lang/rust.svg?maxAge=2592000
Connecting to img.shields.io (img.shields.io)|104.18.44.160|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [image/svg+xml]
Saving to: 'rust.svg?maxAge=2592000'

    [ <=>            ] 741         --.-K/s   in 0,1s    

2016-07-01 10:17:01 (7,32 KB/s) - 'rust.svg?maxAge=2592000' saved [741]

And here I can see both images (hopefully you can too):

Image (with http 301 redirected to https):
Image with http redirect

Same image with https:
Image with https

My conclusion is that if the redirection is done properly then the badges should not break. From my point of view the most likely cause of the errors are:

  • You were using a self-signed certificate that was not trusted by your browser, and it refused to load the image.
  • There was a cache issue with the browser when you were testing the redirection (unless you used CTRL+F5 to force a reload of the page).
  • The redirection was not done properly (by some mistake on your end or a bug at a dokku level)

I may be wrong, but without further reasons on why the badges were broken it is difficult to guess what is going on.

@gaborcsardi
Copy link
Member

@gaborcsardi gaborcsardi commented Jul 2, 2016

It is not so easy, because GH has its own cache, and nobody knows what it does exactly. See e.g. badges/shields#111

@gaborcsardi
Copy link
Member

@gaborcsardi gaborcsardi commented Sep 20, 2016

OK, I am not sure what the problem was last time, but with the new dokku version, I gave it another try today, and everything seems to work fine. All I needed was adding the certificates.

zeehio added a commit to zeehio/condformat that referenced this issue Sep 28, 2016
Thanks to fix in r-hub/cranlogs.app#22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.