Opened 3 years ago

Last modified 3 years ago

#2219 new defect

Space escaping in unquoted strings

Reported by: xavierog@… Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.18.x
Keywords: escaping unquoted Cc:
uname -a: Linux hack03 5.10.0-8-amd64 #1 SMP Debian 5.10.46-1 (2021-06-24) x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.18.0
built with OpenSSL 1.1.1k 25 Mar 2021
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -ffile-prefix-map=/build/nginx-q9LD4J/nginx-1.18.0=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-compat --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_sub_module

Description (last modified by xavierog@…)

Hi,

I was toying with unquoted strings in nginx configuration files when I stumbled upon the following behaviour:

server_name hack03;
location /test/ {
    add_header X-Value omelette\ du\ fromage always;
}

I was expecting:

X-Value: omelette du fromage

I got:

$ nginx -t && nginx -s reload && curl -sI http://hack03/test/ | grep X-Value
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
X-Value: omelette\ du\ fromage

Is this the expected behaviour? It looks like a parsing bug that was never reported because anyone stumbling upon this would immediately switch to a quoted string and forget about it.

Change History (3)

comment:1 by xavierog@…, 3 years ago

Description: modified (diff)

Simplified the nginx configuration snippet.

Last edited 3 years ago by xavierog@… (previous) (diff)

comment:2 by Maxim Dounin, 3 years ago

Only \", \', \\, \t, \r, and \n escape sequences are recognized and replaced with the appropriate character. Everything else is preserved as is, though looses the special meaning, if any (such as in \ , \<tab>, \<CR>, \<LF>, \#, \;, \{, and \} outside of the quoted strings).

As far as I understand, it was primary meant to be used within quoted strings. Probably Igor can provide additional details, I'll try to ask him.

This behaviour probably can be changed to better match shell escaping, where \ is preserved as is in quoted strings, but replaced with a space outside of the quoted strings. I would expect this to cause various configuration breakage though, and also it will obviously make configuration parsing more complicated, so not sure it worth the effort.

Certainly this needs to be better documented though. Currently, configuration file syntax is mostly undocumented, and only defines measurement units to be used in the configuration.

A side note: with the current code,

return 200 \${pid};

results in an error because $ looses its special meaning, and { is interpreted as a block start. This probably needs to be fixed anyway (and see also ticket #640).

comment:3 by xavierog@…, 3 years ago

Some context: I usually stick with quoted strings. I toyed with unquoted strings only because I am currently working on nginx syntax highlighting.
While doing so, I can of course refer to the source code but this lacks an intent (documentation/comments) vs implementation (code) separation.
Consequently, improving the current documentation so as to reflect:

  • the basic rules
  • all possible corner cases
  • in both quoted and unquoted strings

... would be an acceptable fix from my perspective.

Note: See TracTickets for help on using tickets.