Opened 4 years ago
Closed 3 years ago
#2053 closed defect (invalid)
ignore_invalid_headers required, but only for websockets
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | documentation | Version: | 1.18.x |
| Keywords: | Cc: | ||
| uname -a: | FreeBSD nginx 12.1-RELEASE-p7 FreeBSD 12.1-RELEASE-p7 GENERIC amd64 | ||
| nginx -V: |
nginx version: nginx/1.18.0
built with OpenSSL 1.1.1d-freebsd 10 Sep 2019 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --modules-path=/usr/local/libexec/nginx --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_v2_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-pcre --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --with-mail_ssl_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-mail=dynamic --with-stream=dynamic |
||
Description
Hello,
The Fediverse (Mastodon, Pleroma, etc) has been using ActivityPub and the HTTP Signatures draft[1] in the wild for some time now.
We've been building out an optimized federation strategy over Websockets so we can sign the session and continue sending data, limiting the overhead. It seems that we require ignore_invalid_headers on; when this data is passed over a WebSocket due to the header (request-target), as defined in the draft.
This header exists for normal HTTP/1.1 and HTTP/2.0 federation and does not cause any problems. It only causes issues for the Websocket sessions.
The only other HTTP server/proxy I've tested with is Varnish which has not exhibited any problems with this header over Websockets.
[1] https://tools.ietf.org/html/draft-cavage-http-signatures-10
Change History (2)
comment:1 by , 4 years ago
comment:2 by , 3 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
Feedback timeout. As outlined above, from the ticket description it looks like a bug in the client.
As per the draft linked, the
(request-target)is not an HTTP header, but rather a special name to be used in theheaderssignature parameter (2.3. Signature String Construction). It should never appear as a real HTTP header. It should only appear in theheadersparameter or in signature strings.Note well that
ignore_invalid_headers on;is the default. You probably mean to writeignore_invalid_headers off;instead, which will instruct nginx to process invalid headers rather than ignoring them (so, for example, they will be passed to upstream servers). Note though that usingignore_invalid_headers off;might not be a good idea for security reasons. Unless the HTTP Signatures draft is implemented incorrectly,ignore_invalid_headers off;shouldn't be needed.To find out why
ignore_invalid_headers off;is needed in your case, consider looking into nginx error log. It should contain information about ignored headers at theinfolevel (see the error_log directive description for details). If the culprit is indeed the(request-target)header actually present in requests as an HTTP header, you may want to fix the client, it does something wrong.