----- Opprinnelig melding ----- > Hello! Hello!
> On Thu, Mar 27, 2014 at 04:34:37PM +0100, Trygve Vea wrote: > > # HG changeset patch > > # User Trygve Vea <trygve....@redpill-linpro.com> > > # Date 1395933815 -3600 > > # Thu Mar 27 16:23:35 2014 +0100 > > # Node ID 13e6a37c2f57443b0d5dd0abce8d9d4ab00e31e3 > > # Parent 2411d4b5be2ca690a5a00a1d8ad96ff69a00317f > > Added so_freebind and so_transparent to the listen directive > > > > This solves a Linux/IPv6-specific problem. > > > > To be able to listen to an IPv6 address that is not yet available on the > > host, > > one need to use the IP_FREEBIND and IP_TRANSPARENT socket options. > > > > The use case in question is for a failover setup with several service- > > addresses in a IPv6-only environment. > > > > IPv4 has a sysctl available (ip_nonlocal_bind), which is not available for > > IPv6 - thus making these patches necessary. > > Isn't bind on INADDR_ANY/IN6ADDR_ANY works for you? > > It is expected to work fine and allows to accept connections on > all addresses currently available on a host without any > non-portable tricks. ----- Opprinnelig melding ----- > > IPv4 has a sysctl available (ip_nonlocal_bind), which is not available for > > IPv6 - thus making these patches necessary. > > Isn't bind on INADDR_ANY/IN6ADDR_ANY works for you? > > It is expected to work fine and allows to accept connections on > all addresses currently available on a host without any > non-portable tricks. That would be sufficient for HTTP - and my preferred option, since we can handle routing after the end-user have provided us with the Host-header, and thus know where to send the user. However, with SSL enabled - while we have end users that still do not support SNI (http://en.wikipedia.org/wiki/Server_Name_Indication#Client_side), and using multiple SSL-certificates, for multiple applications - we will need to bind each certificate to its own dedicated service address. From here, we can do routing / forward the connections further down the stack. After I submitted the patch, I noticed that it will probably not build on Linux versions prior to 2.4, so I intend to create a new one addressing that issue tomorrow when I'm back at the office. Are there any issues with the patch that I should take into consideration when making changes? Regards -- Trygve Vea _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel