Opened 5 years ago
Closed 5 years ago
#1972 closed defect (wontfix)
Use of IRIs in redirect responses causes nginx to violate HTTP RFCs
Reported by: | Avamander | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | nginx-core | Version: | 1.17.x |
Keywords: | Cc: | ||
uname -a: | 4.15.0-88-generic | ||
nginx -V: | nginx/1.17.10 |
Description
For example when you do this in a server block:
`
return 301 https://ǐri.domain
`
Then nginx nicely sends ǐri.domain
to the client, which can cause issues with things that except ASCII URIs as described in the standard.
Nginx should auto-punycode or warn about such return sentences.
Note:
See TracTickets
for help on using tickets.
It certainly shouldn't auto-punycode. The
return
directive return exactly what is specified as an argument, either in theLocation
header for redirections, or in the HTTP message body for other response codes. The only processing done is the one for local redirections, as explicitly documented. It is not expected to do any escaping, auto-punicode, or whatever. You can think of the second argument as a short way to return a 301 response with a correspondingadd_header Location <text>;
.As for warnings, it is hardly a good idea either. There are at least two basic reasons:
return
directive supports variables, and warnings are either imply checking all the returned redirections (with the corresponding overhead in all cases, and flooding logs with warnings in case there is something wrong), or won't be able to catch significant amount of cases where one can expect warnings.