Add an offline page to display when Discourse is rebuilding or starting up

documentation sysadmin
, ,
41

I’m running Ubuntu 14.04, do you think that Nginx we installed here is supporting http2 ?
Could be this change a help to show the offline page while rebuilding?

PS: Sorry I hadn’t a chance too look at the logs at /var/log/nginx/ as you’d asked. As you may saw I’m facing some other serious problems :frowning: soon I look at it and will come back to you.

1 Like
42

I’m not sure – and I don’t think I have a 14.04 instance lying around to test. But you can easily try it: Add http2 to the listen block, und service reload nginx. If it errors out, it isn’t supported :slight_smile:

1 Like
43

You were right. I had one mistakes in Nginx config. I just fixed it and now the offline page working like charm. Thank you a lot :champagne:

2 Likes
44

For Info: I just had a chance to try it with my 14.04 Ubuntu. It’s not supported. Nginx failed to reload.

1 Like
45

Hmm, wait, @sam complained this turns off http2. But, I upgraded to Ubuntu 16.04 and then changed this line:

listen 443 ssl; listen [::]:443 ssl;

to

listen 443 ssl http2; listen [::]:443 ssl http2;

And it seems to pass http/2 through fine now?

2 Likes
46

Yeah, on 16.04 nginx can do http2.

6 Likes
47

I’ve slightly worded down the warning in the initial post to reflect this. Thanks for confirming, @codinghorror and @Falco!

4 Likes
48

6 posts were split to a new topic: Let’s Encrypt won’t renew with offline page

49

Can you clarify the purpose of adding this header here? It seems it has conflict with embedding comments.

3 Likes
50

No sense at all, at least now, since Discourse returns its own header. I’ll remove it from the howto. Thanks for reporting this!

4 Likes
51

Hi, with the recent version of discourse is this still needed?
Any downside/disadvantage of using this approach?

Why not modify directly the Nginx built in/default with discourse/docker to specify error pages?

52

Because the container needs to running in order to serve pages, and the point of this configuration is to serve an error page when the Discourse app container isn’t running.

7 Likes
53

When you define the ssl_ciphers in nginx like what is proposed here, then your instance doesn’t support TLSv1 and TLSv1.1 anymore. Or at least not in my situation.

2 Likes
54

True that, so you could simplify the configuration by removing the outdated protocols. I’ll do that, thanks!

1 Like
55

I had a Question!!

will using https:// instead of http:// in the above url break or else create any complication into the setup?

56

Why would you want to do that? This traffic never touches the network, there is no reason for HTTPS here.
In this setup, HTTPS is provided entirely by the outer Nginx instance :slight_smile:

57

I asked that because in such a case with wordpress, using a https proxy for a http site will mess up a lot of thing even if one has got site working on both if the url is left http then there are a lot of content warnings at times so I was just curious to know.

anyway thanks for clarification.

1 Like
58

This is taken care of by the headers set by Nginx, especially X-Forwarded-Proto: It tells Discourse that the user-facing protocol is HTTPS :slight_smile:

2 Likes
59

So necessarily it won’t matter if http or https is used in this configuration? right?

Ps: sorry for a noob question, I don’t really know much about http headers

60

If you follow the instructions in the original post, this should work out :+1:

1 Like