Re: [PATCH] SPDY: fixed handling of sc-length in ngx_http_spdy_state_read_data()
On Thursday 27 March 2014 09:02:57 Xiaochen Wang wrote:
hi
On Thu, Mar 27, 2014 at 1:01 AM, Valentin V. Bartenev
vb...@nginx.comwrote:
On Wednesday 26 March 2014 12:30:11 Xiaochen Wang wrote:
In our production, sometimes, the disk was full. In which case, the
requests
after the POST request were handled wrongly in one spdy connection.
Because the input body (DATA frame) of POST request could not be written
to disk,
then ngx_http_spdy_state_read_data() tried to skip this DATA frame with
wrong
sc-length, which broke spdy stream.
[..]
While I agree that there's a problem with sc-length premature adjustment,
but
please note that the problem cannot be triggered by the way you described.
The pos pointer is adjusted as well right before
ngx_write_chain_to_temp_file()
is called.
Yes, the pos pointer is right. But sc-length is not adjusted if it
receives a complete DATA frame.
Then ngx_http_spdy_state_skip() skips more data.
ngx_http_spdy_state_read_data
{
...
if (size = sc-length) {
size = sc-length; sc-length is not adjusted.
complete = 1;
} else {
sc-length -= size;
complete = 0;
}
...
}
Ah, ok, I thought about cases when sc-length is adjusted but *pos isn't,
but you are right there's also an opposite case.
wbr, Valentin V. Bartenev
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
proxy_pass behavior
Hello, Should proxy_pass retry ipv4 if ipv6 fails? Currently (1.5.12), it does not, and there is no way to force proxy_pass to always use ipv4. Specifically, if a proxy_pass host has dual records (A+), proxy_pass seems to only try the . I'm considering submitting a patch if there is support for this. Thanks! -Jim P. ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: proxy_pass behavior
Hello! On Thu, Mar 27, 2014 at 12:29:03PM -0400, Jim Popovitch wrote: Should proxy_pass retry ipv4 if ipv6 fails? Currently (1.5.12), it does not, and there is no way to force proxy_pass to always use ipv4. In no particular order: - The proxy_next_upstream is expected to retry by default. - There _is_ a way to force proxy_pass to always use ipv4 - you should configure your system accordingly, and getaddrinfo(AI_ADDRCONFIG) as used by nginx will do the right thing. E.g., on Linux net.ipv6.conf.all.disable_ipv6 can be set to disable use of ipv6. -- Maxim Dounin http://nginx.org/ ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: proxy_pass behavior
On Thu, Mar 27, 2014 at 12:59 PM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Mar 27, 2014 at 12:29:03PM -0400, Jim Popovitch wrote: Should proxy_pass retry ipv4 if ipv6 fails? Currently (1.5.12), it does not, and there is no way to force proxy_pass to always use ipv4. In no particular order: - The proxy_next_upstream is expected to retry by default. Yes, that works if the host name has 2 or more A OR 2 or more records. proxy_next_upstream does not appear to transition to the next protocol (i.e. from ipv4 to ipv6) - There _is_ a way to force proxy_pass to always use ipv4 - you should configure your system accordingly, and getaddrinfo(AI_ADDRCONFIG) as used by nginx will do the right thing. E.g., on Linux net.ipv6.conf.all.disable_ipv6 can be set to disable use of ipv6. :-) That's unacceptable!! :-) I don't want people to disable ipv6, I want proxy_pass to use ipv6 and upon failure use ipv4. ;-) -Jim P. ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] Added so_freebind and so_transparent to the listen directive
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. -- Maxim Dounin http://nginx.org/ ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: proxy_pass behavior
Hello! On Thu, Mar 27, 2014 at 01:12:18PM -0400, Jim Popovitch wrote: On Thu, Mar 27, 2014 at 12:59 PM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Mar 27, 2014 at 12:29:03PM -0400, Jim Popovitch wrote: Should proxy_pass retry ipv4 if ipv6 fails? Currently (1.5.12), it does not, and there is no way to force proxy_pass to always use ipv4. In no particular order: - The proxy_next_upstream is expected to retry by default. Yes, that works if the host name has 2 or more A OR 2 or more records. proxy_next_upstream does not appear to transition to the next protocol (i.e. from ipv4 to ipv6) It doesn't care about address family. As long as connect() to one address fails, it will try next one. - There _is_ a way to force proxy_pass to always use ipv4 - you should configure your system accordingly, and getaddrinfo(AI_ADDRCONFIG) as used by nginx will do the right thing. E.g., on Linux net.ipv6.conf.all.disable_ipv6 can be set to disable use of ipv6. :-) That's unacceptable!! :-) I don't want people to disable ipv6, I want proxy_pass to use ipv6 and upon failure use ipv4. ;-) It was you who claimed that there is no way to force proxy_pass to always use ipv4. There is. -- Maxim Dounin http://nginx.org/ ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: proxy_pass behavior
On Thu, Mar 27, 2014 at 1:27 PM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Mar 27, 2014 at 01:12:18PM -0400, Jim Popovitch wrote: On Thu, Mar 27, 2014 at 12:59 PM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Mar 27, 2014 at 12:29:03PM -0400, Jim Popovitch wrote: Should proxy_pass retry ipv4 if ipv6 fails? Currently (1.5.12), it does not, and there is no way to force proxy_pass to always use ipv4. In no particular order: - The proxy_next_upstream is expected to retry by default. Yes, that works if the host name has 2 or more A OR 2 or more records. proxy_next_upstream does not appear to transition to the next protocol (i.e. from ipv4 to ipv6) It doesn't care about address family. As long as connect() to one address fails, it will try next one. I will have to do some more tests, but so far 1.5.12 (debian wheezy) does not appear to try the next one if the next one is a different protocol family. - There _is_ a way to force proxy_pass to always use ipv4 - you should configure your system accordingly, and getaddrinfo(AI_ADDRCONFIG) as used by nginx will do the right thing. E.g., on Linux net.ipv6.conf.all.disable_ipv6 can be set to disable use of ipv6. :-) That's unacceptable!! :-) I don't want people to disable ipv6, I want proxy_pass to use ipv6 and upon failure use ipv4. ;-) It was you who claimed that there is no way to force proxy_pass to always use ipv4. There is. What I was trying to claim was that there is no way to run nginx on ipv4 and ipv6 yet force proxy_pass to use only ipv4. Of course you can proxy bind to a v4 interface, but that doesn't scale with syncing configs to multiple servers. Maybe it's time for a proxy_protocol variable. -Jim P. ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] Added so_freebind and so_transparent to the listen directive
- 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
Re: [PATCH] Added so_freebind and so_transparent to the listen directive
Hi Trygve, 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. Non-local bind() isn't Linux-specific feature. FreeBSD has IP_BINDANY/IPV6_BINDANY options and OpenBSD has SO_BINDANY option, so it would be good to add support for all of them. Also, requiring user to add both: so_freebind and so_transparent options to enable single feature doesn't look very user friendly, especially because according to your description, non-local bind() would work just fine with only so_freebind for IPv4 addresses, but it would fail for IPv6 addresses... I don't think that the so_ prefix is necessary, how about just bindany or nonlocal (freebind is just stupid name)? Best regards, Piotr Sikora ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] Added so_freebind and so_transparent to the listen directive
- Opprinnelig melding - Hi Trygve, 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. Non-local bind() isn't Linux-specific feature. FreeBSD has IP_BINDANY/IPV6_BINDANY options and OpenBSD has SO_BINDANY option, so it would be good to add support for all of them. That makes sense. Also, requiring user to add both: so_freebind and so_transparent options to enable single feature doesn't look very user friendly, especially because according to your description, non-local bind() would work just fine with only so_freebind for IPv4 addresses, but it would fail for IPv6 addresses... I don't think that the so_ prefix is necessary, how about just bindany or nonlocal (freebind is just stupid name)? The so_-prefix was something I took from the existing so_keepalive option. Are there any conventions I should follow when I name these values? I agree that creating a single option that can handle multiple platforms the same is a good idea. What if I do something like; * Create a configuration variable for the listen-directive named 'nonlocal'. * If IPv6 and Linux = 2.4, attempt to set the socket options in question. (I'm not sure if I would need to deal with dual stack in a certain way, here - I'll check with one of the IPv6-evangelists at work tomorrow) * If IPv4 and Linux = 2.4, set the IP_FREEBIND socket option. * Else, throw warning that the parameter will be ignored because running on an unsupported platform. Adding support for more platforms for the configuration option can be easily added by someone with access and knowledge about the platforms. I have actually never used FreeBSD/OpenBSD, so my knowledge is fairly limited. Would that be acceptable? -- Trygve ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
