On Wed, 2010-04-28 at 17:43 +0100, Mark McLoughlin wrote:
My instinct was that it's a little too clever clogs, but the more
I
think about it, it might work well
Some thoughts:
- Simple clients will not set this and will be sync, maybe that's fine
- If not, we can add an async param to the body later which would
override the header
- I'd like to see the semantics clarified a bit - e.g. is the
operation guaranteed to be async/sync if the header isn't set. What
does sync even mean in the case of e.g. 'reboot'? Don't return until
the reboot has been completed, or don't return until the VM has
changed from UP to REBOOTING?
It's definitely worth continuing to experiment with the idea - worst
case scenario is that we'll be revert your 'Expect' header code, which
isn't a big deal
OK there's a serious fly in the ointment with this approach.
I wanted to confirm that it works smoothly with real-life servlet
engines, and as expected all is grand with JBoss and bare Tomcat. But
unfortunately Jetty is very pernickety about the Expect header, unless
the expectation is either 100-Continue or 102-Processing it throws back
a 417 "Expectation Failed" without dispatching to the servlet at all. So
this approach would not work on any stack build atop Jetty, e.g. Apache
Geronimo, so regrettably I think its a non-runner as a result.
Interestingly that other expectation actually supported by Jetty,
102-Processing (see [1]), has almost the right semantics. It's used to
indicate that the request will take a long time to process, but instead
of ending the message exchange right there, the full response is
eventually sent over the _same_ connection. Which is not really what we
want ... if we're going to tie up the connection for the duration, might
as well use a traditional synchronous request/200-response.
Cheers,
Eoghan
[1]
http://wiki.eclipse.org/Jetty/Feature/1xx_Responses