doc: AcceptedAlert::write doesn't necessarily write all bytes about rustls HOT 7 CLOSED

Yeah we should fix the example code to deal with short writes for good form.

Though, in practice, there is really zero chance I think that that would ever happen with a real TCP sockets -- the server has written no data, so the write window is at least the MTU (the smallest of which is 68 bytes, and easily fits one alert). Though perhaps it's possible for protocols that upgrade to TLS from another protocol, like SMTP STARTTLS.

from rustls.

Maybe an AcceptedAlert::write_all(&mut io) -> io::Result<()> would improve ergonomics for blocking usage?

from rustls.

I don't think blocking would be the concern since the underlying io is set to non-blocking and so would return ErrorKind::WouldBlock and presumably early-return from the loop. This probably would be fine, since the async wrapper could do something roughly like the following:

return match alert.write(io) {
  Err(e) if e.kind() == ErrorKind::WouldBlock => Poll::Pending,
  other => Poll::Ready(other)
}

The loop in write would likely never continue in async usage because even a successful write is WouldBlock.

from rustls.

Maybe an AcceptedAlert::write_all(&mut io) -> io::Result<()> would improve ergonomics for blocking usage?

That's a good suggestion, thanks. I added a commit for this in #1868 and switched the acceptor example update commit to use it.

from rustls.

Fair point, we've been noticing this stuff in tokio-rustls: rustls/tokio-rustls#48.

from rustls.

Yeah we should fix the example code to deal with short writes for good form.

Here's a quick patch for the doc update & example's usage of AcceptedAlert::write: #1868

It might make sense to do a more systematic evaluation of all the examples + writes as a follow up to make sure we address this holistically.

from rustls.

Good point @jbr - or we could change the behavior of write() to do write_all(), since as @ctz says this would never happen with a real TCP socket. So we would pay the price of possibly blocking an async executor in a very unlikely situation for the convenience of users not having to loop over the result.

from rustls.