Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] disable expect continue support

Hi Simone,

I wasnt aware of the semantics of getInputStream, ie that Jetty would defer sending the 100-Continue until getInputStream was called. My understanding was that Jetty (and other containers) would simply send the 100-Continue prior to invoking

But the process you've described is ideal, and its likely that the problem we're seeing is simply because milton is getting a reference to the inputstream (though not using it) too early.

I'll have a closer look...

Thanks for your help!

BTW: Do you know if other servlet containers implement the same semantics? Or is Jetty just being a bit of a star? I described the same problem to the tomcat users list and responses appear to confirm that 100-Continue is sent prior to invoking the servlet.

Brad


On 14/02/13 04:56, Simone Bordet wrote:
Hi,

On Mon, Feb 11, 2013 at 9:42 PM, Brad McEvoy <brad@xxxxxxxxxxxxxxxxxxxx> wrote:
Hi,

I'm the author of milton.io, a webdav server library for java.

Recently i've been getting increasing number of milton users affected by
Expect:Continue handling in servlet containers such as jetty

The problem is that any servlet container which implements transparent
handling of the Expect header (ie sends the 100 response before invoking the
servlet) causes large performance problems for webdav for many important
clients including Windows and Cyberduck - for example files will often get
uploaded twice.
I am not sure I understand.
The implementation of 100-Continue in Jetty has followed the latest
interpretation that the Http-bis working group has agreed on.

Are you saying that Windows and Cyberduck clients do not implement
correctly 100-Continue and send the content twice ?
And that in order to workaround these buggy clients you would like to
disable 100-Continue support on the server side ?

The Servlet API do not provide any API for handling 100-Continue, so
this must be done by the container, "transparently".
If we don't do it, then we break compliant clients.
What Jetty does is this: if the application calls
HttpServletRequest.getInputStream(), it means that it has figured out
(by looking at the headers) that it can accept the content.
At that point, Jetty sends a 100-Continue response.
Jetty's HTTP client also supports 100-Continue.

We really would like to understand the problem better before adding a feature.
Do you have a dump of the request/response cycles that cause the problem ?

Thanks !

--
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev



Back to the top