On 11.11.22 23:28, Jacob Champion wrote:
> Consider the case where the server sends a
> NegotiateProtocolVersion with a reasonable length, but then runs over
> its own message (either by sending an unterminated string as one of the
> extension names, or by sending a huge extension number). When I test
> that against a client on my machine, it churns CPU and memory waiting
> for the end of a message that will never come, even though it had
> already decided that the maximum length of the message should have been
> less than 2K.
>
> Put another way, why do we loop around and poll for more data when we
> hit the end of the connection buffer, if we've already checked at this
> point that we should have the entire message buffered locally?
Isn't that the same behavior for other message types? I don't see
anything in the handling of the early 'E' and 'R' messages that would
handle this. If we want to address this, maybe this should be handled
in the polling loop before we pass off the input buffer to the
per-message-type handlers.