mirror of
https://github.com/jetty/jetty.project.git
synced 2025-02-24 00:17:18 +00:00
e43b718fb1
Call shutdownOutput to signal the other end that you have written all the data that your are going to write (eg and the end of a non persistent HTTP response). This can be done either by generator (when it is complete) or coordinator or handle - but we need to decide which and have only 1 doing it.
Call shutdownInput to signal your own end that you have read -1 and to allow other local code to check that with an isInputShutdown. Ideally we could get by without any calls at all to shutdownInput, so long as we well handle reading -1 (Currently we don't). This should be done by whatever does the IO read.
Calling close should always be a real TCP close, even with SSL. SSL shutdown
The default handling of an idle callback should be close. But some connections (NOT endpoints) may implement idle as initiating a shutdown exchange (eg websocket close). If they do, this is state that should be held in the connection or parser - ie do-this-exhange-and-then-shutdown
Call close when you want to shutdown Output and you have already read -1, so input is already shutdown. We need to double verify that this is correct and that if a FIN has been received from the other end, that a close will not result in a reset. I'll do that today.
Call close when you want to shutdown Input and output has already been shutdown. This means you have read -1 after having sent a FIN.
Call close on any errors.
The current state is that server HttpConnection appears to be working well. Other connection types have not been updated and/or tested
This is a source checkout of the Jetty webserver. To build, use: mvn install The jetty distribution will be built in jetty-distribution/target/distribution The first build may take a long time as Maven downloads all the dependencies. The tests do a lot of stress testing, and on some machines it is necessary to set the file descriptor limit to greater than 2048 for the tests to all pass successfully.