Fix for #2619 breaks fix for #2603

[jcorporation]

Fix for #2619 breaks fix for #2603

[jcorporation]

@jcorporation Jürgen, can you please check #2720 ? (In both scenarios) Thank you !

It's a pleasure for me to confirm that this patch fixes both scenarios!

[scaprile]

@jcorporation Jürgen, can you please check #2720 ? (In both scenarios) Thank you !

@cpq : I think we've been going back and forth with two corner cases. Using "blame" I can see we've been using mg_tls_pending(), then resorted to c->rtls.len and then back to mg_tls_pending().
I think there are two corner cases here:

• Msg is very short and gets sent along with the headers. mg_tls_pending() returns 0 as it has no data, BUT c->rtls.len > 0 as there is outstanding data after parsing headers. That is #2603 , we fixed it but broke the next scenario
• Msg is of such a length that a whole block, or a group of them, fit the transfer. c->rtls.len is zero, BUT mg_tls_pending() will indicate it has a block to process. That seems to be #2619, its fix goes back to how things were before, causing a regression on the former scenario.

I merged both, and IIRC we've been there before, I remember some chat when we discussed whether both were necessary or not. I think this is real life answering us both.

[cpq]

@scaprile thank you Sergio, makes sense!