<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 26 août 2023 à 14:21, наб <<a href="mailto:nabijaczleweli@nabijaczleweli.xyz" target="_blank">nabijaczleweli@nabijaczleweli.xyz</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Package: nginx<br>
Version: 1.24.0-1<br>
Severity: normal<br>
<br>
Dear Maintainer,<br>
<br>
Test setup:<br>
-- >8 --<br>
#!/bin/sh<br>
printf '%s\n' "Status: ${DOCUMENT_URI##*/}" 'Content-Type: text/plain' '' "${DOCUMENT_URI##*/}"<br>
-- >8 --<br>
in /tmp/cgi and<br>
-- >8 --<br>
server {<br>
listen <a href="http://127.1.2.3:80" rel="noreferrer" target="_blank">127.1.2.3:80</a>;<br>
location / {<br>
fastcgi_pass unix:/run/fcgiwrap.socket;<br>
include /etc/nginx/fastcgi_params;<br>
fastcgi_param SCRIPT_FILENAME /tmp/cgi;<br>
}<br>
}<br>
-- >8 --<br>
in /etc/nginx/sites-enabled/demo.<br>
<br>
Naturally, this program returns "Status: {request path without /}",<br>
with body "{request path without /}" and whatever padding to make<br>
it palatable to nginx.<br>
<br>
Now, the abridged bug (full log attached, but it's not exciting):<br>
-- >8 --<br>
$ curl -s -vvv <a href="http://127.1.2.3/'404%20Zupa" rel="noreferrer" target="_blank">http://127.1.2.3/'404%20Zupa</a>' 2>&1 | cat -A<br>
> GET /404%20Zupa HTTP/1.1^M$<br>
< HTTP/1.1 404 Zupa^M$<br>
< Server: nginx/1.24.0^M$<br>
404 Zupa$<br>
<br>
$ curl -s -vvv <a href="http://127.1.2.3/'404%20" rel="noreferrer" target="_blank">http://127.1.2.3/'404%20</a>' 2>&1 | cat -A<br>
> GET /404%20 HTTP/1.1^M$<br>
< HTTP/1.1 404^M$<br>
< Server: nginx/1.24.0^M$<br>
404 $<br>
<br>
$ curl -s -vvv <a href="http://127.1.2.3/'404" rel="noreferrer" target="_blank">http://127.1.2.3/'404</a>' 2>&1 | cat -A<br>
> GET /404 HTTP/1.1^M$<br>
< HTTP/1.1 404^M$<br>
< Server: nginx/1.24.0^M$<br>
404$<br>
<br>
$ curl -s -vvv <a href="http://127.1.2.3/'40" rel="noreferrer" target="_blank">http://127.1.2.3/'40</a>' 2>&1 | cat -A<br>
> GET /40 HTTP/1.1^M$<br>
< HTTP/1.1 502 Bad Gateway^M$<br>
< Server: nginx/1.24.0^M$<br>
<html>^M$<br>
<head><title>502 Bad Gateway</title></head>^M$<br>
<body>^M$<br>
<center><h1>502 Bad Gateway</h1></center>^M$<br>
<hr><center>nginx/1.24.0</center>^M$<br>
</body>^M$<br>
</html>^M$<br>
-- >8 --<br>
(yes, I straced fcgiwrap, it doesn't mangle the Status lines).<br>
<br>
Case-wise:<br>
"404 Zupa" correct! it's a valid 404<br>
"40" correct! it's invalid, 502ing is sensible<br>
but<br>
"404 " wrong!<br>
"404" wrong!<br>
<br>
Both are normalised by nginx to "HTTP/1.1 404",<br>
which is invalid accd'g to RFC9112 (I think that's the current standard?):<br>
<a href="https://www.rfc-editor.org/rfc/rfc9112.html#name-collected-abnf" rel="noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc9112.html#name-collected-abnf</a><br>
which says<br>
start-line = request-line / status-line<br>
status-code = 3DIGIT<br>
status-line = HTTP-version SP status-code SP [ reason-phrase ]<br>
<br>
Naturally, nginx is producing a status-line without the second SP,<br>
which is wrong!<br>
<br>
Repros on sid and bookworm.<br></blockquote><div><br></div><div>Forwarded to nginx mailing list, should appear here:</div><div><a href="https://mailman.nginx.org/pipermail/nginx/2023-August/thread.html">https://mailman.nginx.org/pipermail/nginx/2023-August/thread.html</a><br></div><div><br></div><div>Jérémy</div><div><br></div><div><br></div><div><br></div></div></div>