Namaste misc,
Overview:
With the caveat that my abilities are limited to reading code and basic
admin, I think that the "location [not] found" feature in httpd(8)
might possibly be "featuritis" - incorrectly using a term borrowed from
reyk@.
If I may go further, I think we might want to revert the feature
completely.
Introduction:
Firstly, tusen takk pigeonflight (pf) expert from Norge for the 6.9-beta
announcement on undeadly and even more gratitude for the volks who
assemble the excellent changelog [1].
While browsing through the changelog, I came across the following:
"
Created a new "location (found|notfound)" option for httpd.conf(5) to
allow testing for resource path existence.
"
Understanding Use Case:
In order to understand the use case, I looked at the diff thread [2],
and failed to understand the purpose behind the diff based on the
canonical example.
The canonical example quoted in the diff is:
"
...
server "www.example.com" {
listen on * port www
directory index "index.php"
location not found "/*" {
request rewrite "/index.php"
}
location "/*.php" {
fastcgi socket "/run/php-fpm.sock"
}
}
...
"
In fact, I am not entirely sure that httpd(8) should be patched with new
features so that "Wordpress Pretty Permalinks" can work.
Understanding Use Case - Part Deux:
Since I am stupid, I tried reading the httpd.conf(5) manpage [3]:
"
location [[not] found] path {...}
Specify server configuration rules for a specific location. The path
argument will be matched against the request path with shell globbing
rules. Optionally, it is also possible to match for found (i.e.
accessible) or not found request paths only. In case of multiple
location statements in the same context, the first matching location
statement will be put into effect, while all later ones will be ignored.
Therefore it is advisable to match for more specific paths first and for
generic ones later on. A location section may include most of the server
configuration rules except alias, connection, hsts, listen on, location,
tcp and tls.
location [[not] found] match path {...}
Like the location option, but match the path using pattern matching
instead of shell globbing rules, see patterns(7). The pattern may
contain captures that can be used in an enclosed block return or request
rewrite option.
"
Armed with the above knowledge, I again tried to understand the
canonical example quoted in the diff.
But as stated earlier, I am stupid, and could not understand what the
"location not found /*" - a catch-all - accomplishes. The path of
execution eluded me - would it not be the case that everything would
match the path "/*", and since it is to be "not found" or logically
inverted - that location block would never be executed.
More importantly, I could not come up with a use case where a "location
found" could be used.
Questions Of A Stupid Mind:
1) Where would one use "location found" vs the good old plain "location"
- is it not the default assumption that things are "found"?
2) Would it not be a classic 404 if something is "not found"?
3) How is it a 500 if something is "not found" - when did not finding a
resource become "Internal Server Error"?
Finding Memo:
Searching for "location found" in the mail archives led to another
thread on tech@ [4], where the diff to add "location found" in the
example on acme-client(1) manpage was not accepted. This further made me
think that probably I may not be alone in my line of thinking - danke
fobser@, merci benno@.
To [F]CGI And Beyond:
Since I do not understand the execution itself, I could not understand
how "[not] found" would interact with [f]cgi.
Due to the same reason, I could not assess the impact on httpd(8)
performance because of accessing on-disk file paths while evaluating a
location block.
Finally, I think there might have been some reason why reyk@ has
separate server_http.c [5], server_file.c [6] and server_fcgi.c [7]
files. In fact, sys/stat.h and fcntl.h are introduced in server_http.c
by this diff.
The End:
This is a long mail already, so in conclusion, I think we may want to
better understand the use case, other than the need for "Wordpress
Pretty Permalinks".
And until then, I think we might want to revert the feature completely.
Dhanyavaad,
ab
[1] - https://www.openbsd.org/plus.html
[2] - https://marc.info/?l=openbsd-tech&m=160378647900970
[3] - https://man.openbsd.org/httpd.conf.5
[4] - https://marc.info/?l=openbsd-tech&m=160432668217674
[5] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/server_http.c
[6] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/server_file.c
[7] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/server_fcgi.c
---------|---------|---------|---------|---------|---------|---------|--
