nginx config generated by nginx-boot.sh does bogus 301 redirects about gatsby-docker

[torenware]

@polarathene , much thanks for looking at this. Looks like absolute_redirect is indeed the ticket. I've just pushed a PR that turns that off, and turns port_in_redirect on. That appears to work w/o modifying anything else.

Not sure what the side-effects are of these two settings (I see chatter that they are used when you put a proxy in front of nginx), but the fix does make my site work.

[polarathene]

In the reproduction repo you provided me via the Discord group, I was able to confirm the issue.

http://localhost:8001/k8s would redirect to a trailing slash with the port removed. If you gave the trailing slash path from the start(http://localhost:8001/k8s/, this seems to work properly without redirecting to the dropped port.

If the setting enables port_in_redirect, it will instead add the nginx listen port(customizable via $HTTP_PORT as per README), so if you alter that from the default 80 to say 8002, then the docker mapping 8001:8002 will load http://localhost:8001/k8s/ fine, once JS kicks in, the url is modified to drop the trailing /, refreshing http://localhost:8001/k8s, then has nginx redirect to http://localhost:8002/k8s/(note the port change).

absolute_redirect being disabled seems to be the preferred way. As the docs say it performs a relative redirect, not absolute, this seems to not mess with the port.

[torenware]

This works better, but it still doesn't work right.

I've figured out a way to test this issue that does not involve my repo at all:

1. Start up the container using the PR on port 8001 (-p 8001:80).
2. Go to the link http://localhost:8001/does-not-exist/. You will get the Gatsby 404 page.
3. Now go to the link http://localhost:8001/does-not-exist. You will get redirected to http://localhost/no-link/ and get the "Cannot load page" page for your browser.

This behavior is the same irrespective of what TRAILING_SLASH is set to, which likely is itself a bug (but one bug at a time...).

[torenware]

Turns out that the in the land of nginx redirects, the relative redirect is king.

It can be a little confusing to test this, since your browser remembers if you've done a 301. But using curl makes for a clearer test as to what the server is actually doing:

$ curl -v http://localhost:8001/does-not-exist > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8001 (#0)
> GET /does-not-exist HTTP/1.1
> Host: localhost:8001
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Sun, 21 Jun 2020 21:45:51 GMT
< Content-Type: text/html
< Content-Length: 162
< Connection: keep-alive
< Location: /does-not-exist/
<
{ [162 bytes data]
100   162  100   162    0     0   8951      0 --:--:-- --:--:-- --:--:--  9000
* Connection #0 to host localhost left intact

And for the alternative:

$ curl -v http://localhost:8001/does-not-exist/ > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8001 (#0)
> GET /does-not-exist/ HTTP/1.1
> Host: localhost:8001
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Server: nginx
< Date: Sun, 21 Jun 2020 21:46:06 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 11103
< Connection: keep-alive
< Vary: Accept-Encoding
< ETag: "5eefd289-2b5f"
<
{ [11103 bytes data]
100 11103  100 11103    0     0  1292k      0 --:--:-- --:--:-- --:--:-- 1355k
* Connection #0 to host localhost left intact

I'm not sure what the use case is for the Docker image, but this behavior meets my needs. FWIW.