Configure nginx, matching current Apache config #8

sideshowbarker · 2017-09-02T06:20:27Z

No description provided.

foolip

Some initial comments, have to make waffles now.

foolip · 2017-09-02T07:04:26Z

debian/marquee/03-nginx-conf

@@ -0,0 +1,16 @@
+#!/bin/bash -e


Can you delete all the apache files and renumber these? They're in git history if we want to go back. certbot will need some tweaking. On bgsound I have mkdir -p /var/www/http/.well-known/acme-challenge/ in 00-nginx-conf and certbot certonly -n --agree-tos --webroot -m admin@whatwg.org -d $domain -w /var/www/http in 01-certbot. There will be a TODO about reloading nginx when new certs are issued too.

foolip · 2017-09-02T07:05:15Z

debian/marquee/03-nginx-conf

+chown -R deploy:deploy /var/www
+rm -rf /var/www/html
+
+/usr/sbin/nginx -t


why is the path needed?

/usr/sbin/nginx -t

why is the path needed?

Not needed—I’ll change it to just nginx

foolip · 2017-09-02T07:06:30Z

debian/marquee/03-nginx-conf

+rm -rf /var/www/html
+
+/usr/sbin/nginx -t
+systemctl start nginx.service


It will be running after the install, so restart. And is this different from nginx -s reload?

It will be running after the install, so restart.

OK

And is this different from nginx -s reload?

Yes, reload causes it to just re-read/re-evaluate the config, without restarting. But if nginx is for some reason not running at the point, then reload won’t start it but I guess will just fail.

But even if nginx is stopped restart will cause it start (after loading the config).

So it seems like restart is what we do want here, right?

Yes, nginx -s reload fails with nginx: [error] open() "/run/nginx.pid" failed (2: No such file or directory) if it's not running. I found sudo systemctl reload-or-restart nginx.service which seems to work even if not running, and with any luck it'll reload when possible. I'm guessing that'll avoid dropping ongoing connections.

foolip · 2017-09-02T07:07:07Z

debian/marquee/04-nginx-sites

+cp nginx/sites/*.conf /etc/nginx/sites-available/
+
+for domain in `cat DOMAINS | tr , ' '`; do
+    ln -s /etc/nginx/sites-available/$domain.conf /etc/nginx/sites-enabled/


This is nicer than what I'd been doing, thanks!

foolip · 2017-09-02T07:07:21Z

debian/marquee/04-nginx-sites

+    ln -s /etc/nginx/sites-available/$domain.conf /etc/nginx/sites-enabled/
+done
+
+/usr/sbin/nginx -t


Ditto questions.

/usr/sbin/nginx -t

Ditto questions.

Changed to just nginx and restart there too

foolip · 2017-09-02T07:29:34Z

debian/marquee/nginx/conf/http.conf

+server {
+    listen 80 default_server;
+    listen [::]:80 default_server;
+    server_name _;


Is this needed?

server_name _;

Is this needed?

I’m actually not sure. The nginx docs say:

If no server_name is defined in a server block then nginx uses the empty name as the server name.

So I’ve always the convention of setting the name to _ and can say from experience I know that’s never caused any problems—but can’t say I know from experience I know that leaving it unset so the “empty name” gets used doesn’t cause any problems.

But anyway I’ll test it and see.

server_name _;

Is this needed?

I’ll test it and see.

I’ve now tested and can’t find that it causes any problems. From reading the docs and thinking about it, I guess the only thing it would ever affect is requests that don’t send the Host header. So that’s something we don’t need to care about anyway—since no browsers ever do that, and it’s non-conforming anyway (in HTTP 1.1 and 2 at least). And nginx itself rejects such requests with a 400 Bad Request before ever evaluating against the config.

Keeping this or omitting it is fine, whatever you think is clearer.

foolip · 2017-09-02T07:32:10Z

debian/marquee/nginx/conf/http.conf

+    listen 80 default_server;
+    listen [::]:80 default_server;
+    server_name _;
+    return 301 https://$host$request_uri;


To make the webroot certbot thing work, we'll need:

location ^~ /.well-known/acme-challenge/ { default_type application/jose+json; } location / { return 301 https://$host$request_uri; }

Wait, we don't redirect other URLs than / or does this mean something else?

Documentation is at http://nginx.org/en/docs/http/ngx_http_core_module.html#location, didn't actually read it, but this syntax amounts to a prefix match, not an exact match.

To make the webroot certbot thing work, we'll need:

location ^~ /.well-known/acme-challenge/ { default_type application/jose+json; } location / { return 301 https://$host$request_uri; }

OK, added

domenic

Super excited about this, and about learning more about nginx.

domenic · 2017-09-02T13:18:50Z

debian/marquee/nginx/sites/books.spec.whatwg.org.conf

@@ -0,0 +1,13 @@
+server {
+    listen 443 ssl http2;
+    listen [::]:443 ssl http2;


Can we move these to whatwg.conf?

Or http.conf? What's the difference between http and whatwg?

I think http.conf is for not-HTTPS.

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

Can we move these to whatwg.conf?

No we can’t. Each server block needs to have its own listen directive; otherwise the server gets defaulted to port 80:

https://nginx.org/en/docs/http/ngx_http_core_module.html#listen

If the directive is not present then either *:80 is used if nginx runs with the superuser privileges, or *:8000 otherwise.

https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms#parsing-the-quot-listen-quot-directive-to-find-possible-matches

By default, any server block that does not include a listen directive is given the listen parameters of 0.0.0.0:80 (or 0.0.0.0:8080 if Nginx is being run by a normal, non-root user).

And there’s no config option to override that; it’s hardcoded into the nginx sources:

https://github.com/nginx/nginx/blob/3900d1cb3cf39963d909604923f7e7af6ecf99fd/src/http/ngx_http_core_module.c#L2775-L2784

Or http.conf? What's the difference between http and whatwg?

I think http.conf is for not-HTTPS.

Yeah, the only purpose of http.conf is just to redirect non-HTTPS to HTTPS.

But as far as why both http.conf and whatwg.conf are needed: because http.conf gets put into the /etc/nginx/conf.d directory, and anything that’s put there gets included once in the main top-level nginx http {…} block. But the stuff in whatwg.conf needs to get included into multiple places, in the server {…} blocks for each virtual server (domain).

Each server block needs to have its own listen directive

Huh, and including such a directive via include doesn't mean "having" it?

Each server block needs to have its own listen directive

Huh, and including such a directive via include doesn't mean "having" it?

Ah, I hadn’t thought about just putting it in whatwg.conf. But I’ve now moved it there and it works find that way, so I’ll commit that change—thanks

Did that work out, can you push those changes?

Did that work out, can you push those changes?

It did work, and I’ve now pushed the changes I‘ve made so far. I will wrap up the rest and push them later today.

domenic · 2017-09-02T13:19:29Z

debian/marquee/nginx/sites/books.spec.whatwg.org.conf

+    server_name books.spec.whatwg.org;
+
+    ssl_certificate /etc/letsencrypt/live/books.spec.whatwg.org/fullchain.pem;
+    ssl_certificate_key /etc/letsencrypt/live/books.spec.whatwg.org/privkey.pem;


Could we move these to whatwg.conf and use some kind of templating to determine the file name?

ssl_certificate /etc/letsencrypt/live/books.spec.whatwg.org/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/books.spec.whatwg.org/privkey.pem;

Could we move these to whatwg.conf and use some kind of templating to determine the file name?

No, because nginx doesn’t itself have any kind of templating mechanism or static macros for use in config files. So I think the only way to do that would be to use a runtime variable in the ssl_certificate and ssl_certificate_key values—specifically, $server_name —if that even worked, which it doesn’t.

To confirm that, I tried putting ssl_certificate /etc/letsencrypt/live/${server_name}/fullchain.pem and ssl_certificate_key /etc/letsencrypt/live/${server_name/privkey.pem in whatwg.conf and removing from all the sites/*.conf files. That caused nginx to fail at startup with BIO_new_file("/etc/letsencrypt/live/${server_name}/fullchain.pem").

Because nginx evaluates that value statically at startup, I guess at that point ${server_name} is undefined or null, since it’s something that only gets set at runtime.

But even if it worked, I think the problem there is that it would be expensive in that nginx variables are basically all runtime variables that require a lookup per-request.

The nginx docs have an FAQ that discusses the general issue:

https://nginx.org/en/docs/faq/variables_in_config.html

Ah, great, thanks for the education!

It does make me think we should perhaps be generating these files using some templating system, but we can do that later, if ever. Not a big deal for now.

It does make me think we should perhaps be generating these files using some templating system

Agreed, that would be better for maintenance

but we can do that later, if ever. Not a big deal for now.

Yeah, I think once we finally have all the domains moved over, we can go and back and set something up that we can design and test with all cases as a complete set

foolip

Finished my review, looking good!

foolip · 2017-09-03T17:39:12Z

debian/marquee/03-nginx-conf

+
+apt install nginx
+
+# a2dissite doesn't work if nothing is enabled


This comment was for the apache config, left behind.

foolip · 2017-09-03T17:40:15Z

debian/marquee/03-nginx-conf

+# a2dissite doesn't work if nothing is enabled
+rm -f /etc/nginx/sites-enabled/*
+
+cp -p nginx/conf/http.conf /etc/nginx/conf.d/


Why preserve ownership etc.? Isn't it better if these files are owned by root?

cp -p nginx/conf/http.conf /etc/nginx/conf.d/

Why preserve ownership etc.?

No good reason. Will drop the -p

Isn't it better if these files are owned by root?

yes

foolip · 2017-09-03T17:45:53Z

debian/marquee/03-nginx-conf

+rm -rf /var/www/html
+
+/usr/sbin/nginx -t
+systemctl start nginx.service


Yes, nginx -s reload fails with nginx: [error] open() "/run/nginx.pid" failed (2: No such file or directory) if it's not running. I found sudo systemctl reload-or-restart nginx.service which seems to work even if not running, and with any luck it'll reload when possible. I'm guessing that'll avoid dropping ongoing connections.

foolip · 2017-09-03T17:46:23Z

debian/marquee/nginx/conf/http.conf

+server {
+    listen 80 default_server;
+    listen [::]:80 default_server;
+    server_name _;


Keeping this or omitting it is fine, whatever you think is clearer.

foolip · 2017-09-03T17:48:03Z

debian/marquee/nginx/conf/http.conf

+    listen 80 default_server;
+    listen [::]:80 default_server;
+    server_name _;
+    return 301 https://$host$request_uri;


Documentation is at http://nginx.org/en/docs/http/ngx_http_core_module.html#location, didn't actually read it, but this syntax amounts to a prefix match, not an exact match.

foolip · 2017-09-03T18:22:02Z

debian/marquee/nginx/sites/books.spec.whatwg.org.conf

+
+    include /etc/nginx/whatwg.conf;
+
+    return 301 https://books.idea.whatwg.org$request_uri;


For idea↔spec redirects I think we should use HTTP 302, as 301 may be cached, and we might move things between. This was a bit of a nuisance with https://whatwg.org/faq.

foolip · 2017-09-03T18:23:56Z

debian/marquee/nginx/sites/figures.spec.whatwg.org.conf

+
+    include /etc/nginx/whatwg.conf;
+
+    return 301 https://figures.idea.whatwg.org$request_uri;


Suggest 302 per above.

foolip · 2017-09-03T18:25:49Z

debian/marquee/nginx/sites/domparsing.spec.whatwg.org.conf

+
+    include /etc/nginx/whatwg.conf;
+
+    return 301 https://w3c.github.io/DOM-Parsing$request_uri;


Hmm, this matches the apache config, but maybe we should omit $request_uri, as basically nothing in https://github.com/whatwg/domparsing exists in https://github.com/w3c/DOM-Parsing

foolip · 2017-09-03T18:26:33Z

debian/marquee/nginx/sites/help.whatwg.org.conf

+
+    include /etc/nginx/whatwg.conf;
+
+    return 301 https://html.spec.whatwg.org/dev;


Add a slash to avoid another redirect.

foolip · 2017-09-03T18:33:08Z

debian/marquee/nginx/sites/fetch.spec.whatwg.org.conf

+    ssl_certificate /etc/letsencrypt/live/fetch.spec.whatwg.org/fullchain.pem;
+    ssl_certificate_key /etc/letsencrypt/live/fetch.spec.whatwg.org/privkey.pem;
+
+    include /etc/nginx/whatwg.conf;


https://fetch.spec.whatwg.org/commit-snapshots/ is now 403 forbidden but wasn't before. @domenic, does it matter?

I browse that directory index pretty often for the various specs; it would be nice to have one if nginx has that feature.

@sideshowbarker, maybe a whatwg-spec.conf that does the extra things?

Yeah, we should have a directory listing of sorts.

https://fetch.spec.whatwg.org/commit-snapshots/ is now 403 forbidden but wasn't before. @domenic, does it matter?

I browse that directory index pretty often for the various specs; it would be nice to have one if nginx has that feature

OK, fixed that and now all /commit-snapshots paths are browsable.

foolip · 2017-09-03T18:40:00Z

debian/marquee/nginx/sites/n.whatwg.org.conf

+        autoindex_exact_size off;
+    }
+
+    rewrite /work https://html.spec.whatwg.org/multipage/microdata.html#licensing-works;


https://n.whatwg.org/workz and https://n.whatwg.org/bla/work are also redirected with this. I guess that's harmless, but maybe ^/work$ or a location = /work { return ... } would be better?

Yeah, this should be location most likely. We don't want to redirect all the things.

https://n.whatwg.org/workz and https://n.whatwg.org/bla/work are also redirected with this. I guess that's harmless, but maybe ^/work$ or a location = /work { return ... } would be better?

Yeah, this should be location most likely. We don't want to redirect all the things.

OK, fixed.

foolip · 2017-09-04T21:53:43Z

@sideshowbarker, can you make sure 6b72735 (mimesniff and xhr) are also included? Those should be the last of the current "easy" ones, the rest have something special about deploy to resolve first.

foolip · 2017-09-04T22:29:57Z

@sideshowbarker, https://resources.whatwg.org/fonts/README.md now has the wrong content-type, application/octet-stream.

This replaces the ssl_ciphers value with the current value from using “Modern” at https://mozilla.github.io/server-side-tls/ssl-config-generator/

@foolip

Untested. @foolip please make sure this is what it should be.

See https://nginx.org/en/docs/http/ngx_http_headers_module.html#expires Because `expires max` auto-sets Cache-Control to 10 years, we shouldn’t set an explicit Cache-Control too—because that ends up causing nginx to send two Cache-Control headers.

sideshowbarker · 2017-09-05T06:26:59Z

@sideshowbarker, can you make sure 6b72735 (mimesniff and xhr) are also included? Those should be the last of the current "easy" ones, the rest have something special about deploy to resolve first.

Yup, added

sideshowbarker · 2017-09-05T06:35:28Z

https://resources.whatwg.org/fonts/README.md how has the wrong content-type, application/octet-stream

Yeah, see https://github.com/nginx/nginx/blob/master/conf/mime.types. Apparently, by default nginx doesn’t recognize .md files as text/plain.

So, added a mapping in whatwg.conf

sideshowbarker · 2017-09-05T06:43:46Z

OK, I’ve responded to all review comments here—so please re-review and merge if there are no new changes needed.

I think #8 (comment) (what cache headers+values we should send) is the only remaining thing from the review comments here that might still require further changes. And I’ve raised #10 for that, so if there are no new changes needed for anything else here otherwise, I suggest that we not block on that caching question but instead go ahead and merge this.

This overrides 03acfb9 to replaces the ssl_ciphers value with the current value from using “Intermediate” at https://mozilla.github.io/server-side-tls/ssl-config-generator/ instead of “Modern”—because using the “Modern” ssl_ciphers value also apparently disable both TLSv1.1 and TLSv1.0 (which it’s not clear we agree we want to do yet).

sideshowbarker · 2017-09-05T07:30:31Z

I found sudo systemctl reload-or-restart nginx.service which seems to work even if not running, and with any luck it'll reload when possible.

OK—thanks for finding that, switched to using it

I'm guessing that'll avoid dropping ongoing connections.

I thought a plain restart would also not drop any ongoing connections but would instead wait for them to close before stopping and restarting

foolip · 2017-09-05T09:08:27Z

I thought a plain restart would also not drop any ongoing connections but would instead wait for them to close before stopping and restarting

Could be, I haven't done any testing.

foolip · 2017-09-05T09:09:59Z

return 301 https://$host$request_uri;
Documentation is at http://nginx.org/en/docs/http/ngx_http_core_module.html#location, didn't actually read it, but this syntax amounts to a prefix match, not an exact match

OK, so is there some change you think we still need to make there?

That was about http.conf, and I think that's fine.

foolip · 2017-09-05T09:12:52Z

debian/marquee/00-nginx-conf

+chown -R deploy:deploy /var/www
+rm -rf /var/www/html
+
+mkdir -p /var/www/http/.well-known/acme-challenge


I was going to say put this before the chown, but maybe it's just as well that it's after so that only root can create files there? On marquee it's currently owned by the deploy user, so one needs to change.

I was going to say put this before the chown, but maybe it's just as well that it's after so that only root can create files there? On marquee it's currently owned by the deploy user, so one needs to change.

I’ve moved it before the chown. It doesn’t seem like having only root be able to create files there needs to be a big concern

foolip · 2017-09-05T09:13:45Z

debian/marquee/01-certbot

@@ -2,6 +2,6 @@

 apt install certbot python-certbot-apache

-for domains in `cat DOMAINS`; do
-    certbot certonly -n --apache --agree-tos -m admin@whatwg.org -d $domains
+for domain in `cat DOMAINS`; do


This should actually be plural, because it can be a value like "whatwg.org,www.whatwg.org" and documentation says "-d DOMAINS Comma-separated list of domains to obtain a cert for"

foolip · 2017-09-05T09:15:05Z

debian/marquee/01-certbot

@@ -2,6 +2,6 @@

 apt install certbot python-certbot-apache


Drop python-certbot-apache. Also rebase and rm -rf debian/marquee/apache/, some things are still left.

foolip · 2017-09-05T09:20:09Z

debian/marquee/nginx/conf/whatwg.conf

+
+include whatwg-headers.conf;
+
+location ~* \.(?:ico|css|js|gif|jpe?g|png|svg)$ {


Thanks, let's figure it out separately.

foolip · 2017-09-05T09:20:35Z

debian/marquee/nginx/conf/whatwg.conf

+    include whatwg-headers.conf;
+}
+
+location /commit-snapshots {


branch-snapshots too

foolip · 2017-09-05T09:23:21Z

debian/marquee/nginx/conf/whatwg.conf

+    autoindex_exact_size off;
+}
+
+include mime.types;


Can you add a comment about why this is necessary given that it's also included in the main nginx.conf?

foolip · 2017-09-05T09:44:25Z

debian/marquee/nginx/conf/whatwg.conf

+
+include mime.types;
+types {
+    text/plain md;


I ran find *whatwg.org -type f -name '*.*' | sed 's#.*/##' | sed 's/.*[.]//' | sort | uniq on the existing servers and found these file extensions:

appcache cgi css gif gz htaccess (ignore) html ico include (ignore) jpeg jpg js json map md mp4 ogv old pdf png sh svg swp ttf txt woff woff2 xml zip

Can you check that all of these have the correct type still?

(Also looked for extension-less files, updated description of #7 to not forget them. There are none affected by this PR.)

I ran find *whatwg.org -type f -name '*.*' | sed 's#.*/##' | sed 's/.*[.]//' | sort | uniq on the existing servers and found these file extensions:
…
Can you check that all of these have the correct type still?

OK, I went through and checked all those and added any that were missing.

Some comment and questions:

cgi

We don’t need anything for .cgi, right?

map

What is that?

ogv

Added video/ogg per https://www.iana.org/assignments/media-types/video/ogg

old

What is that?

swp

Don’t think we need that :)

ttf

Added font/ttf per https://www.iana.org/assignments/media-types/font/ttf

woff2

Added font/woff2 per https://www.iana.org/assignments/media-types/font/woff2

ttf, woff2, and ogv lack mappings in /etc/apache2/mods-available/mime.conf too, so I left comments in whatwg.conf to make it clear where the mappings come from

sideshowbarker · 2017-09-05T21:53:02Z

I think #8 (comment) (what cache headers+values we should send) is the only remaining thing from the review comments here that might still require further changes. And I’ve raised #10 for that, so if there are no new changes needed for anything else here otherwise, I suggest that we not block on that caching question but instead go ahead and merge this

In d5dd1f6 I’ve removed that one ad-hoc thing I had there that was adding Expires and Cache-Control. It’s not essential and whatever we add for the long term will just fall out from the #10 investigation and discussions

See mozilla/server-side-tls#135 > proper rotation of session ticket encryption key is not > implemented in nignx or Apache. Thus it is easier to recommend against > its use that suggest use of 3rd party software to fix it. > The problem is not that they are insecure, or that they can't be made > secure. The problem is that the way they are commonly implemented means > that you don't provide forward secrecy if you use them - all encryption > keys are ultimately encrypted with just one encryption key - the session > ticket key. > > see here for more in-depth explanation: > https://www.imperialviolet.org/2013/06/27/botchingpfs.ht

sideshowbarker · 2017-09-06T00:33:08Z

https://mozilla.github.io/server-side-tls/ssl-config-generator/?
I think we should do modern btw and disable TLSv1.

If we do change to Modern, then we should also remember to remove the ssl_dhparam line:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

Because with the Modern settings, that won’t be used at all any longer, so we could just drop it.

This change sets ssl_session_timeout & ssl_session_cache to the values recommended by https://mozilla.github.io/server-side-tls/ssl-config-generator/ But I’m not sure what the rationale for those recommended values is, so I’ve also raised mozilla/server-side-tls#198 in hopes of getting an explanation.

sideshowbarker · 2017-09-06T04:01:39Z

I’ve changed ssl_session_timeout and ssl_session_cache to the values recommended at https://mozilla.github.io/server-side-tls/ssl-config-generator/ but I’m not sure what the specific rationale for those recommended values is, so I’ve also raised mozilla/server-side-tls#198

foolip · 2017-09-06T08:14:23Z

FWIW, I think we should err on the side of supporter older clients (keeping TLSv1) when we're just serving static content, can we have an issue about that change and start out matching the current config?

annevk · 2017-09-06T08:18:45Z

I guess we can start out conservative, sure. My main argument for going with TLSv12 only is that we're supposed to set an example and I'd expect all our end users to have modern hardware and software.

annevk

Couple minor nits.

annevk · 2017-09-06T09:55:58Z

debian/marquee/nginx/conf/whatwg.conf

+gzip_comp_level 6;
+gzip_buffers 16 8k;
+gzip_http_version 1.1;
+gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml image/svg+xml application/xml+rss text/javascript;


Remove application/x-javascript as we don't care for it?

annevk · 2017-09-06T09:57:45Z

debian/marquee/nginx/sites/javascript.spec.whatwg.org.conf

+
+    include /etc/nginx/whatwg.conf;
+
+    return 301 https://github.com/tc39/ecma262/labels/web%20reality;


Maybe make this a 302?

annevk · 2017-09-06T09:57:56Z

debian/marquee/nginx/sites/domparsing.spec.whatwg.org.conf

+
+    include /etc/nginx/whatwg.conf;
+
+    return 301 https://w3c.github.io/DOM-Parsing/;


annevk · 2017-09-06T09:58:13Z

debian/marquee/nginx/sites/mediasession.spec.whatwg.org.conf

+
+    include /etc/nginx/whatwg.conf;
+
+    return 301 https://wicg.github.io/mediasession/;


annevk · 2017-09-06T09:58:40Z

debian/marquee/nginx/sites/webvtt.spec.whatwg.org.conf

+
+    include /etc/nginx/whatwg.conf;
+
+    return 301 https://w3c.github.io/webvtt$request_uri;


foolip · 2017-09-06T22:53:12Z

debian/marquee/nginx/conf/whatwg.conf

+
+include whatwg-headers.conf;
+
+location /commit-snapshots {


Previous comment has been collapsed, so: branch-snapshots too.

foolip · 2017-09-06T23:08:46Z

debian/marquee/nginx/conf/http.conf

+    }
+    location / {
+        return 301 https://$host$request_uri;
+    }


Oops, an important detail is missing here:

root /var/www/http;

Had to put that on marquee to get a new cert.

foolip

Yay, thanks Mike!

Configure nginx, matching current Apache config

6a173fb

sideshowbarker requested a review from foolip September 2, 2017 06:21

foolip reviewed Sep 2, 2017

View reviewed changes

domenic reviewed Sep 2, 2017

View reviewed changes

foolip reviewed Sep 3, 2017

View reviewed changes

foolip mentioned this pull request Sep 3, 2017

Write tests for redirects and SSL certs #9

Closed

sideshowbarker added 8 commits September 5, 2017 04:03

fixup! Configure nginx, matching current Apache config

e8ece12

fixup! Configure nginx, matching current Apache config

f37c79a

Make ssl_ciphers match SSL configurator “Modern”

03acfb9

This replaces the ssl_ciphers value with the current value from using “Modern” at https://mozilla.github.io/server-side-tls/ssl-config-generator/

Drop Apache scripts & rename/renumber nginx ones

38c358b

Make certbot use .well-known/acme-challenge thing

96be045

Untested. @foolip please make sure this is what it should be.

Make /commit-snapshots browsable

528ac24

Add xhr.spec & mimesniff.spec

c54b7bd

Make nginx serve .md files as text/plain

b59d7bc

sideshowbarker mentioned this pull request Sep 5, 2017

Decide what caching headers (if any) to send for more “static” resources #10

Closed

sideshowbarker added 4 commits September 5, 2017 06:58

fixup! Configure nginx, matching current Apache config

3adb224

Don’t clobber all of default mime.types

52854be

Use systemctl reload-or-restart nginx.service

d5fe2e8

Add stuff needed for webroot certbot thing

8b8d909

foolip reviewed Sep 5, 2017

View reviewed changes

sideshowbarker added 2 commits September 5, 2017 21:46

Remove Apache config files

14708ca

Remove add-hoc caching

d5dd1f6

sideshowbarker added 5 commits September 5, 2017 21:55

fixup! Configure nginx, matching current Apache config

ad89a6d

fixup! Configure nginx, matching current Apache config

0f77a6e

fixup! Configure nginx, matching current Apache config

9a7397f

Add mappings for some missing MIME types

9b60019

apt install certbot

356922d

more slash to avoid redirect

aaabc0e

annevk reviewed Sep 6, 2017

View reviewed changes

foolip reviewed Sep 6, 2017

View reviewed changes

sideshowbarker added 5 commits September 7, 2017 14:47

Allow directory indexes everywhere

f736a5c

Add root /var/www/http for port 80 server

41fc3e7

Drop gzipping of application/x-javascript

2285d9d

MIME-assign text/javascript map

1ca5868

Give Anne some 302s

eff4684

foolip approved these changes Sep 7, 2017

View reviewed changes

sideshowbarker merged commit 526311f into master Sep 8, 2017

sideshowbarker deleted the mike/nginx branch September 8, 2017 04:52


		apt install nginx

		# a2dissite doesn't work if nothing is enabled


		include /etc/nginx/whatwg.conf;

		return 301 https://books.idea.whatwg.org$request_uri;


		include /etc/nginx/whatwg.conf;

		return 301 https://figures.idea.whatwg.org$request_uri;


		include /etc/nginx/whatwg.conf;

		return 301 https://w3c.github.io/DOM-Parsing$request_uri;


		include /etc/nginx/whatwg.conf;

		return 301 https://html.spec.whatwg.org/dev;


		include whatwg-headers.conf;

		location ~* \.(?:ico\|css\|js\|gif\|jpe?g\|png\|svg)$ {


		include /etc/nginx/whatwg.conf;

		return 301 https://github.com/tc39/ecma262/labels/web%20reality;


		include /etc/nginx/whatwg.conf;

		return 301 https://wicg.github.io/mediasession/;


		include /etc/nginx/whatwg.conf;

		return 301 https://w3c.github.io/webvtt$request_uri;

Configure nginx, matching current Apache config #8

Configure nginx, matching current Apache config #8

Conversation

sideshowbarker commented Sep 2, 2017

foolip left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sideshowbarker Sep 2, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

foolip left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

foolip commented Sep 4, 2017 • edited

foolip commented Sep 4, 2017 • edited

sideshowbarker commented Sep 5, 2017

sideshowbarker commented Sep 5, 2017

sideshowbarker commented Sep 5, 2017

sideshowbarker commented Sep 5, 2017

foolip commented Sep 5, 2017

foolip commented Sep 5, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sideshowbarker commented Sep 5, 2017

sideshowbarker commented Sep 6, 2017

sideshowbarker commented Sep 6, 2017

sideshowbarker Sep 2, 2017 •

edited

foolip commented Sep 4, 2017 •

edited

foolip commented Sep 4, 2017 •

edited