nginx config minor bug fixed

[SnorlaxYum]

without ^~, resources in folders like /static cannot be accessed.
So I do this PR. It's a minor one in the doc. So I think there's no need to create an issue for it.

[jsjoeio]

@bpmct or @code-asher could you review this? I haven't used nginx so not sure I can help much here.

[codecov]

Codecov Report

Merging #4312 (cb5286a) into main (8a4ed5a) will increase coverage by 0.12%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #4312      +/-   ##
==========================================
+ Coverage   68.09%   68.22%   +0.12%     
==========================================
  Files          31       31              
  Lines        1586     1586              
  Branches      308      308              
==========================================
+ Hits         1080     1082       +2     
+ Misses        432      430       -2     
  Partials       74       74              

Impacted Files	Coverage Δ
src/node/cli.ts	82.30% <0.00%> (+0.82%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8a4ed5a...cb5286a. Read the comment docs.

[code-asher]

I am not sure if we should add this. ^~ means that if this is the longest matching prefix string (meaning not a regular expression match) then skip checking regular expressions matches. In the configuration we provide there are no other location blocks so this is not needed. Is there an example use case for where this is necessary?

[SnorlaxYum]

without ^~, I'll encounter 404 responces when the code server page tries to access resources with the uri like /static/b37ff28a0a582aee84a8f961755d0cb40a4081db/usr/lib/code-server/vendor/modules/code-oss-dev/out/vs/workbench/workbench.web.api.nls.js (and it is a usual case in the default setting).
after adding ^~, it began working.
Another option is add a same block with / changed to /static, which also works.

[jawnsy]

It's always better IMO to avoid using regular expressions as they are harder to maintain (harder for developers to read/understand) and can also lead to reDOS vulnerabilities. If we can duplicate a block in the config to achieve the same behavior, I think that's a preferable solution

[SnorlaxYum]

okay, I changed by duplicating the block for /static.

[jsjoeio]

If we can duplicate a block in the config to achieve the same behavior, I think that's a preferable solution

Good call! @code-asher I'll let you give the final approval here

[code-asher]

I still do not understand what this is fixing. The default / location block will handle /static. You can verify the configuration works as-is using Docker with these steps: ``` $ docker run --rm -it -p 8080:80 ubuntu bash $ apt update && apt install curl nginx $ curl -fsSL https://code-server.dev/install.sh | sh $ code-server --auth none & $ cat > /etc/nginx/sites-available/default << EOF server { listen 80 default_server; listen [::]:80 default_server; server_name _; location / { proxy_pass http://localhost:8080/; proxy_set_header Host \$host; proxy_set_header Upgrade \$http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Accept-Encoding gzip; } } EOF $ nginx $ tail -f /var/log/nginx/access.log # Just to make sure nginx is being used. ``` From here I browsed to localhost:8080 and confirmed everything loads correctly including /static, /vscode-remote-resource, etc. Would you be able to provide a reproduction of the problem this is solving? Thank you!

[SnorlaxYum]

server_name _; location / { proxy_pass http://localhost:8080/; proxy_set_header Host $host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Accept-Encoding gzip; }

It works in localhost address

user@server:~$ curl -D - http://localhost/static/b37ff28a0a582aee84a8f961755d0cb40a4081db/usr/lib/code-server/vendor/modules/code-oss-dev/out/vs/workbench/workbench.web.api.js
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 10 Oct 2021 11:31:35 GMT
Content-Type: application/javascript; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: public, max-age=31536000
ETag: W/"92590f-QMJQGw95m3noobzbN86uvuHM308"
Vary: Accept-Encoding
Content-Encoding: gzip

Now I use the similar conf on my domain (from /etc/nginx/conf.d/default.conf):

server {
       #listen 80;
       #listen [::]:80;
       listen 443 ssl http2;

       server_name aaa.snorl.ax;

       ssl_certificate /etc/letsencrypt/live/snorl.ax/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/snorl.ax/privkey.pem;
       ssl_trusted_certificate /etc/letsencrypt/live/snorl.ax/chain.pem;
       include security.conf;
       include general.conf;

       #root /var/www/example.com;
       #index index.html;
       #error_page 400 502 /404.html;

       location / {
          proxy_pass http://localhost:8080/;
          proxy_set_header Host $host;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection upgrade;
          proxy_set_header Accept-Encoding gzip;
       }

}

Then:

user@server:~$ curl -D - https://aaa.snorl.ax/static/b37ff28a0a582aee84a8f961755d0cb40a4081db/usr/lib/code-server/vendor/modules/code-oss-dev/out/vs/workbench/workbench.web.api.js
HTTP/2 404
server: nginx
date: Sun, 10 Oct 2021 12:03:52 GMT
content-type: text/html; charset=utf-8
content-length: 146
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
referrer-policy: no-referrer-when-downgrade
content-security-policy: default-src * data: 'unsafe-eval' 'unsafe-inline'
strict-transport-security: max-age=31536000; includeSubDomains; preload

<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

Now I add ^~ (from /etc/nginx/conf.d/default.conf):

server {
       #listen 80;
       #listen [::]:80;
       listen 443 ssl http2;

       server_name aaa.snorl.ax;

       ssl_certificate /etc/letsencrypt/live/snorl.ax/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/snorl.ax/privkey.pem;
       ssl_trusted_certificate /etc/letsencrypt/live/snorl.ax/chain.pem;
       include security.conf;
       include general.conf;

       #root /var/www/example.com;
       #index index.html;
       #error_page 400 502 /404.html;

       location ^~ / {
          proxy_pass http://localhost:8080/;
          proxy_set_header Host $host;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection upgrade;
          proxy_set_header Accept-Encoding gzip;
       }
}

Then:

user@server:~$ curl -D - https://aaa.snorl.ax/static/b37ff28a0a582aee84a8f961755d0cb40a4081db/usr/lib/code-server/vendor/modules/code-oss-dev/out/vs/workbench/workbench.web.api.js
HTTP/2 200
server: nginx
date: Sun, 10 Oct 2021 12:16:30 GMT
content-type: application/javascript; charset=utf-8
cache-control: public, max-age=31536000
etag: W/"92590f-QMJQGw95m3noobzbN86uvuHM308"
vary: Accept-Encoding
content-encoding: gzip
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
referrer-policy: no-referrer-when-downgrade
content-security-policy: default-src * data: 'unsafe-eval' 'unsafe-inline'
strict-transport-security: max-age=31536000; includeSubDomains; preload

Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.

I tested the duplicated one (too long so I didn't added to this paragraph), it just didn't work. So basically ^~ is the only solution.

[code-asher]

Thank you for the additional details. I tried to replicate using a domain instead of localhost but everything still works normally for me. Is that your full config? It seems likely there is something in your config that is interfering with the static endpoint (maybe in the security.conf or general.conf files).

[jsjoeio]

@SnorlaxYum were you able to try @code-asher's suggestion? Hoping we can either close or move forward!

[jsjoeio]

@SnorlaxYum we haven't heard from you in a couple days so I'm going to assume you fixed your issue. I'm going to close this PR. If you want to discuss getting this in, feel free to open an issue and we'll work with you!