Ok thanks for the info :) I wonder if it would be possible to periodically return 100-continue to check if the connection is closed or not? This is not ideal, but this kind of polling may be the best I can achieve for now.
Thanks On Tue, Nov 8, 2011 at 5:09 PM, Simone Bordet <[email protected]> wrote: > Hi, > > On Tue, Nov 8, 2011 at 17:26, Matthew Painter > <[email protected]> wrote: > > Sorry, let me outline a better example :) > > Say that a user requests a page in a browser that is serviced by a > servlet > > that uses jetty continuations. This servlet kicks off some long running > HTTP > > request to another API (say 1 minute), and suspends the request. When > this > > HTTP request is finished, the data from the proxied request is processed, > > and the continuation resumed, and data passed back to the user. > > This is all good. But what if the original HTTP request is cancelled by > the > > user in the browser? Can we detect this, complete the continuation, and > > cancel the proxied HTTP request somehow? > > No. When the user e.g. closes the browser, the connection is closed, > but the server does not currently detect this when a request is > suspended and the connector is the SelectChannelConnector (which is > Jetty's default). > When the proxied request returns, Jetty will try to write the > response, find a closed connection, and close the server-side end of > that connection. > > Simon > -- > http://cometd.org > http://intalio.com > http://bordet.blogspot.com > ---- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
