server: enable holding back acceptor alerts #147
Conversation
|
I don't mind adopting this as a possibility, but definitely needs to be defend with tests. (And, ideally the referenced example code is executed to ensure it behaves as desired.) |
Co-authored-by: John Howard <[email protected]>
| } | ||
|
|
||
| /// Configure whether to send a TLS alert on failure. | ||
| pub fn send_alert(mut self, send: bool) -> Self { |
There was a problem hiding this comment.
@howardjohn what is the purpose of this? It doesn't make sense to me. If send_alert is true, we've sent the alert before this is reachable. If send_alert is false, I think you can only call this without taking out either the io or the alert, and there's no way you can actually check what the server received, I think?
|
|
||
| match alert.write(&mut SyncWriteAdapter { io, cx }) { | ||
| Ok(0) => return Poll::Ready(Ok(())), | ||
| Ok(_) => continue, |
There was a problem hiding this comment.
Pretty sure this is wrong. In case of a partial write, just calling alert.write() again is wrong, since it'll duplicate the parts of the alert that were sent previously.
(Presumably it would be exceedingly rare to get a partial write, but still...)
| LazyConfigAcceptor::new(rustls::server::Acceptor::default(), sstream).send_alert(false); | ||
| tokio::pin!(acceptor); | ||
|
|
||
| let Ok(accept_result) = time::timeout(Duration::from_secs(3), acceptor.as_mut()).await else { |
There was a problem hiding this comment.
@howardjohn you added a bunch of timeouts here which don't really seem necessary? This is a pretty controlled environment, so it feels excessive?
@howardjohn please take a look if this can address your use case. If so, could you add some test coverage for it?
(I do wonder if at this point it would be easier to just address the non-TLS input case more directly...)
Fixes #146.