Fix #2603: TLS read path #2607
Fix #2603: TLS read path #2607
Conversation
| if (n == MG_IO_ERR && mg_tls_pending(c) == 0 && c->rtls.len == 0) { | ||
| if (n == MG_IO_ERR && c->rtls.len == 0) { | ||
| // Close only if we have fully drained both raw (rtls) and TLS buffers |
There was a problem hiding this comment.
Should we also check for mg_tls_pending() as before ? Otherwise I think the comment is not accurate
There was a problem hiding this comment.
Good question - but I am unsure about that.
It looks like we might not need mg_tls_pending() at all.
TLS exchanges data by so-called "records", with "record length" specified at the beginning of the "record". so I expect TLS code to retrieve data from c->rtls by records. Meaning, if c->rtls is empty, there could not be anything pending. But that's a theory, that's why I did not remove mg_tls_pending() yet.
I suggest to give it some runway and see.
There was a problem hiding this comment.
That seems to be implementation dependent. If it drains the transport buffer until it fills a record, then we need a pending function; if it checks the buffer and then retrieves a whole record, leaving whatever may remain, then we don't.
As this is just for connection closure, not having outstanding data seems a good reason to close anyway.
No description provided.