Opened 4 years ago

Closed 4 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


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.

Change History (1)

comment:1 by Maxim Dounin, 4 years ago

Resolution: wontfix
Status: newclosed

It certainly shouldn't auto-punycode. The return directive return exactly what is specified as an argument, either in the Location 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 corresponding add_header Location <text>;.

As for warnings, it is hardly a good idea either. There are at least two basic reasons:

  • Warnings will prevent people from doing things they intended to, even if these things break some standards.
  • The 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.
Note: See TracTickets for help on using tickets.