Custom Query (2297 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (88 - 90 of 2297)

Ticket Resolution Summary Owner Reporter
#437 fixed Add Support for SPDY/3 Valentin V. Bartenev Edward Ackroyd
Description

Please add support for spdy version 3. spdy/2 support has been removed from the Firefox code base ( https://bugzilla.mozilla.org/show_bug.cgi?id=912550 ) and Firefox >= 27 will only support >= spdy/3. Firefox 27 will be released in January 2014 ( https://wiki.mozilla.org/RapidRelease/Calendar ) so there is some urgency in getting spdy/3(.1) support into nginx.

#2470 invalid Add support for the systemd directive OpenFile= for passing UNIX socket FDs to nginx erik.sjolund@…
Description

nginx currently supports specifying a UNIX socket path with the proxy_pass configuration directive

For example

proxy_pass http://unix:/tmp/backend.socket:/uri/;

(reference: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass )

Instead of specifying a path to the UNIX socket, I would like to pass in a file descriptor for the UNIX socket to nginx via inheritance from the parent process that starts nginx (i.e., systemd).

Feature request: Add support for specifying a UNIX socket via the new systemd directive

OpenFile=

(see https://www.freedesktop.org/software/systemd/man/systemd.service.html#OpenFile=) which is available in systemd 253 (released 15 February 2023).

systemd connects to the UNIX socket and lets nginx inherit the file descriptor.

I have not yet investigated how systemd sets the environment variable LISTEN_FDNAMES. (I could provide more details later).

Rationale

This new feature would make it possible to set up a systemd system service with the systemd configuration USER=myuser and GROUP=mygroup and use nginx to proxy traffic to a UNIX socket that the user myuser:mygroup does not have file permission access to. The reason myuser:mygroup is able to use the UNIX socket is that systemd (running as root) has already connected to the socket.

#1183 fixed Add support for variables (or pool) inside ssl_certificate / ssl_certificate_key directives sunnybear@…
Description

Nginx directives ssl_certificate / ssl_certificate_key leak variables support, so for now it's impossible to have generic nginx config for multiple websites listening to 443 port (each with its own cert).

As I understand ssl_certificate is important on config compilation phase (stapling, oscp, etc) - nginx restart - and can't be provided dynamically (on HTTP request phase). But there can be another way - i.e. ssl_certificates pool - which can be used dynamically on SNI requests based on HTTP Host header (and hosts can be obtained from certificates itself).

Any way to provide generic nginx config with multiple 'on-fly' SSL certificates is affordable. But the best way (from my point of view) is to provide support for either (1) or (2) configuration:

(1) server { listen 443 ssl http2; server_name website1.com website2.com; ssl_certificate ssl/certifiates/$host.crt; ssl_certificate_key ssl/certificates/$host.key; }

(2) server { listen 443 ssl http2; server_name website1.com website2.com; ssl_certificate_pool ssl/certifiates/website1.crt; ssl_certificate_pool ssl/certifiates/website2.crt; }

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.