Resolved [PPP-53248] nginx not returning 404 for non-existing files larger than 1023 bytes

[Monty]

Hello again

I recently discovered an interesting problem and I'd like to share that with you and get your opinion on it before I file a bug report.

Summary: nginx does not return a 404 error when requesting a non-existing static file with a trailing slash in the URL for files larger than 1023 bytes

Steps to reproduce:

1. Install CentOS 7 64bit, standard installation, all updates applied
2. Install Plesk Obsidian using the one-click installer with default settings (wget -O - https://autoinstall.plesk.com/one-click-installer | sh)
3. Log in to Plesk and create a hosting for a domain. Do not change anything else.
4. Create two files in the httpdocs folder, one of 1023 bytes size and one of 1024 bytes size:

tr -dc A-Za-z0-9 </dev/urandom | head -c 1023 >1023.html​

tr -dc A-Za-z0-9 </dev/urandom | head -c 1024 >1024.html​

Now perform the following tests:

• Load the URL:
  https://domain.tld/1023.html
  => Content of the file is shown as expected
• Load the same URL with a trailing slash:
  https://domain.tld/1023.html/
  => 404 not found page is shown, as expected
• Load the URL:
  https://domain.tld/1024.html
  => Content of the file is shown as expected
• Load the same URL with a trailing slash:
  https://domain.tld/1024.html/
  => Content of the file is shown, HTTP status code 200 instead of 404

Note:

• You can add any path after the trailing slash (like
  https://domain.tld/1024.html/blah/123/test.html
  ), it will always return a HTTP status code of 200 and the content of the file instead of the 404 error page.
• If I bypass nginx (curl https://domain.tld:7081/1024.html/ then I get the correct answer (404 error)

Workaround:

• Disable "Smart static files processing" in "Apache & nginx settings" then the behaviour is as expected (404 error) when loading the URL with the trailing slash for the 1024 byte file.

Pretty interesting behaviour, eh? I'm trying to figure out where this 1024 byte limit originates from but maybe somebody of you has a smart idea....?

 

[Nik G]

hello @Monty ,

the bug is confirmed.
We will fix it in the nearest Obsidian update (18.0.36) which will be released soon.

Unfortunately the reason of this behavior is unclear for now.

And thank you for this report - you help us to make Plesk better.

 

[weltonw]

I noticed this was fixed in 18.0.36 - purely out of curiosity, is Plesk able to shed some light into what caused this?

 

[Nik G]

@john0001 ,

behavior of mod_aclr2 changed if request contains trailing path
such request should be rejected by default or if AcceptPathInfo is set to Off

 

[Schlaubi]

After auto updating to 18.0.36 our Node.js WebSocket backend (a) production) was no longer available for any client. We restored previous VM image and are currently investigating the issue one a second (fresh) plesk installation (already 18.0.36, b) ). During setup second new plesk identical like first, we discovered following issue:

In "Apache & nginx Settings" we configure some "Additional nginx directives". To get it work (enable websocket clients to connect to our websocket backend) we have:
a) production (restored 18.0.35) : "location /api1/"
b) second fresh (18.0.36): "location api1"

api1 isn't a directory or a file. It's just an url suffix for backend versioning.

If we remove slashes on a), clients cannot connect anymore. If we add slashed on b) clients cannot connect anymore. In the error case of b) proxy_error_log shows

[error] 11523#0: *149 connect() failed (111: Connection refused) while connecting to upstream, client: 1.2.3.4, server: xxx.yyy.com, request: "GET /api1/healthcheck HTTP/1.1", upstream: "http://127.0.0.1:8001/api1/healthcheck", host: "xxx.yyy.com"

Could your fix be responsible for our problems after updating a) to 18.0.36?

 

[Nik G]

@Schlaubi,
an proxy_error_log looks like processing of this location was routed to the apache,
which did not respond (need to check apache logs).

It is necessary to check what exactly location was processed in fact
and how really this location handled

It would be better to submit this issue to the support (with the link to this forum thread or mention to ppp-53248)
so we can investigate it more dipper.

Based on provided info I can't answer is this a result of our fix or not.