"404" pages on stats.jenkins.io served with 200 OK status code

[chris48s]

Service(s)

stats.jenkins.io

Summary

Example: https://stats.jenkins.io/plugin-installation-trend/not-a-plugin.stats.json
Would it be possible to serve these with a 404 Not Found status in the headers?

Reproduction steps

curl --include "https://stats.jenkins.io/plugin-installation-trend/not-a-plugin.stats.json"

[dduportal]

Looks like this issue is a combination of 2 things:

• The behavior of the frontend framework used on the new site for which we did the following fix: fix(stats.jenkins.io): enable try_files directive to allow direct links kubernetes-management#5595
• This "fix" does not take in account the "merge" of files following the migration (Replacing existing stats.jenkins.io code with https://github.com/jenkins-infra/stats.jenkins.io #4265)

[lemeurherveCB]

• The behavior of the frontend framework used on the new site for which we did the following fix: fix(stats.jenkins.io): enable try_files directive to allow direct links kubernetes-management#5595

This behavior seems to always have been the same even before the fix.
Ex: https://stats.jenkins.io/notanurl

• This "fix" does not take in account the "merge" of files following the migration (Replacing existing stats.jenkins.io code with https://github.com/jenkins-infra/stats.jenkins.io #4265)

I'm not sure to follow, can you explain what you mean by "the merge of files following the migration"?

[dduportal]

• The behavior of the frontend framework used on the new site for which we did the following fix: fix(stats.jenkins.io): enable try_files directive to allow direct links kubernetes-management#5595

This behavior seems to always have been the same even before the fix. Ex: https://stats.jenkins.io/notanurl

• This "fix" does not take in account the "merge" of files following the migration (Replacing existing stats.jenkins.io code with https://github.com/jenkins-infra/stats.jenkins.io #4265)

Before adding the try_files, Nginx was acting as a standard HTTP server: if the requested resource does not exist on the filesystem, then it answers HTTP/404. That was the case with https://stats.jenkins.io/notanurl (you can test it locally if you want).

Adding the try_files added changed the default behavior to "Hey nginx, if you do not find a file (HTTP/404), please serve index.html instead (HTTP/200) and delegate routing to the client because it's a Javascript framework with its own client-side routing".
Adding the try_files with the current configuration was tested only with the new site frontend in mind and it worked well.

However, now we've learnt that other files must be served, then it means the current try_files setup need to be updated ton only keep this behavior on the frontend routes. And keep the older behavior on other routes.

I'm not sure to follow, can you explain what you mean by "the merge of files following the migration"?

That was a written shortcut to describe the PR you sent where you "merge" a file tree from the GH branch gh-pages into the public file tree.

[smerle33]

the new routing is correcting the error code for the old path.

so this call will reply with a 404: https://stats.jenkins.io/plugin-installation-trend/not-a-plugin.stats.json
and this one a 200 but 404 from the JS framework: https://stats.jenkins.io/statistics/not-a-correct-path

while all those will work with 200:
https://stats.jenkins.io/
https://stats.jenkins.io/statistics
https://stats.jenkins.io/plugin-trends
https://stats.jenkins.io/plugin-versions
https://stats.jenkins.io/dep-graph
https://stats.jenkins.io/pluginversions
https://stats.jenkins.io/plugin-installation-trend