Opened 3 years ago
Last modified 3 years ago
#2219 new defect
Space escaping in unquoted strings
| Reported by: | 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 )
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:2 by , 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 , 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.
