Partial backports of the following commits from trunk:
6c804b6b2ca2 net.http: Pass server name along for SNI (fixes#1408)
75d2874502c3 net.server_select: SNI support (#409)
9a905888b96c net.server_event: Add SNI support (#409)
adc0672b700e net.server_epoll: Add support for SNI (#409)
d4390c427a66 net.server: Handle server name (SNI) as extra argument
Some lines seem to have gotten the wrong indentation, possibly caused by
Meld which often ignores lines with only whitespace changes and leaves
their previous indentation.
These are triggered all the time by random HTTPS connections, so they
are mostly just useless noise. When you actually do need them, you
probably have debug logging enabled too, since these messages are fairly
useless without more context.
Saves creating a string that'll be identical to buffer[1] anyways, as
well as a C function call. Depending on Lua version and length of the
string, this could be reusing an interned string, but a longer one would
probably be duplicated for no reason.
Having exactly one item in the buffer seems like it would be fairly
common, but I have not done an extensive study. If opportunistic writes
are enabled then it will be even more likely.
This special case could be optimized like this in table.concat but it
does not look like it is.
In :onreadable, if there is still buffered incoming data after reading
from the socket (as indicated by the :dirty method, usually because
LuaSocket has an 8k buffer that's full but it read a smaller amount),
another attempt to read is scheduled via this :pausefor method. This is
also called from some other places where it would be pointless to read
because there shouldn't be any data.
In the delayed read case, this should report that the socket is "dirty".
If it reports that the socket is "clean" then the question is where
the buffer contents went?
If this doesn't get logged after the scheduled time (0.000001s by
default) then this would suggests a problem with timer or scheduling.
If a chunk of data has been received that is larger than the amount read
at a time, then the connection is paused for a short time after which it
tries to read some more. If, after that, there is still more data to
read, it should do the same thing. However, because the "want read" flag
is removed and was restored after the delayed reading, it would not
schedule another delayed read.
A Direct TLS connection (eg HTTPS) gets turned into a LuaSec handle
before the :updatenames call done in the :connect method. LuaSec does
not expose the :getpeername and :getsockname methods, so the addresses
remain obscured, making debugging trickier since the actual IP addrerss
connected to does not show up.
mod_proxy65 calls link twice, once for each direction. This would
overwrite the listeners with one that has the previous listeners as
metatable.__index, but none of the others.
This takes advantage of 94c584d67533 to improve this.
Kim Alvefur