One other behavior I've observed, nginx has an ssl_buffer_size ( http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_buffer_size) option that defaults to 16kb. As I decrease its value, I start seeing the same body size != content length errors from clients. I tried experimenting with tune.idletimer to force the use of large ssl buffers (tune.ssl.maxrecord's default of no limit seems > than 16kb so I didn't bother adjusting it) but I'm still seeing errors. From my reading of the docs, a stream must be idle for 1s by default before the larger ssl buffers are used. It also seems a stream must be idle for at least 1ms before the large buffers are available. Is that correct? Is there a way to always use the larger ssl buffers without this detection? I'm not sure what a stream represents in this context.
On Fri, Apr 2, 2021 at 9:19 AM Willy Tarreau <[email protected]> wrote: > On Thu, Apr 01, 2021 at 06:48:59PM -0700, Nathan Konopinski wrote: > > Sorry about that. Here's a capture of the problem. Clients report errors > > when they get two TLS app data packet responses. Nginx always sends a > > single and haproxy usually but not always sends a single. The content > > length of the response is always the same, just under 13.9kb.[image: > > mailing_list.jpg] > > Well, it should be irrelevant, as the TLS layer is free to segment its > records as it desires. It's even valid to send everything in 1-byte > records. So either these two records happen when there's something else > and are just the visible symptom of another problem, or the client > doesn't process records correctly. > > At this point I have no idea, and TLS tends to leave me speechless as > usual since it's designed to prevent debugging :-( > > Willy >
