1

I am using the Milton WebDAV server (1.6.8) with an embedded Grizzly servlet container (2.1.7), and in their default configuration, PUT requests (at least as issued by Cyberduck) do not work. I have tracked the issue down to a problem with how HTTP 100 Continue is handled (it apparently also affects Jetty), a message on the Milton mailing list and bug tracker says it is the fault of the servlet container, which tries to be clever with "transparent expect/continue handling".

Yes, containers which transparently handle expect continue effectively break HTTP security for Webdav. HTTP uses a challenge/response security model and many clients rely on that. Ie if doing a PUT they will simply do an un-authenticated PUT and rely on ExpectContinue to ensure that the challenge is issued before the file is uploaded.

But with transparent handling of ExpectContinue the entire file gets uploaded before the milton API is able to check if the current user is authenticated and authorised to perform the action.

Depending on your supported clients and you use cases this can either be wholely unacceptable, a nuisance or not an issue at all.

But, generally, I think you should try to find out if Grizzly's transparent handling can be disabled, and then re-enable support in milton.

What can I do to disable Grizzly's transparent expect/continue handling, and is this really correct approach? The alternative would be to turn off expect/continue handling in Milton, but that seems to break WebDAV authentication.

Update: I also tried Jetty now (8.1.0.RC1), and it exhibits the same behaviour as Grizzly: only with expect/continue handling turned off can I PUT files, with the default settings it does not work.

Community
  • 1
  • 1
Thilo
  • 257,207
  • 101
  • 511
  • 656

2 Answers2

1

Regarding Grizly 2.x, you need to override sendAcknowledgment method in your ServletHandler like the following:

class MyServletHandler extends ServletHandler
{
    protected boolean sendAcknowledgment(final Request request,
        final Response response)
        throws IOException
    {
        if (authClient(request, response)
        {
            return super.sendAcknowledgment(request, response);
        }
        else
        {
            response.setStatus(HttpStatus.EXPECTATION_FAILED_417);
            return false;
        }
    }
}

Hope it will help.

eeerahul
  • 1,629
  • 4
  • 27
  • 38
alexey
  • 1,959
  • 10
  • 9
  • Tried that, but did not work. Also put a breakpoint in, but it did not go there. Who is supposed to call `sendAcknowledgement` and when? From what I can see, Milton just sets a status code to SC_CONTINUE and finishes request processing. – Thilo Dec 13 '11 at 12:28
  • will dig deeper tomorrow, but for now it seems that `sendAcknowledgement` gets called not on my ServletHandler, but on the HttpHandlerChain. – Thilo Dec 13 '11 at 12:59
  • pls. try the latest Grizzly 2.1.8 – alexey Dec 13 '11 at 22:34
  • Now it does get called. I swear there was no 2.1.8 yesterday ;-). But what is `authClient`? – Thilo Dec 14 '11 at 00:02
  • we've just released 2.1.8 :) authClient() is nothing, just an example of "any" logic you can implement there. – alexey Dec 14 '11 at 00:40
  • Is there some tutorial about how this is supposed to work? Because `sendAcknowledgment` is being called as the result of my auth logic, which sends 100-continue to prompt the client to send more information. Will the "continued" data (i.e. the Auth headers) be available at that time? I was under the impression that there is another round-trip involved first. Of course, maybe I completely misunderstand something here. – Thilo Dec 14 '11 at 01:05
  • Its a shame that this is a grizzly specific fix, since Jetty does the same thing and (i think) tomcat. – Brad at Kademi Dec 14 '11 at 05:29
  • Thilo: there will be no another headers exchange, after receiving 100-Continue, client will send just a body. brad: you mean it's a shame that servlet spec doesn't cover this? :) – alexey Dec 14 '11 at 11:02
  • @brad: Do you mean to say that Jetty and Tomcat also have the same issue (I just tried Jetty 8.1.0.RC1 and that seems to be the case). What servlet container works better with Milton, then? – Thilo Dec 22 '11 at 09:39
0

Note that whether or not the transparent expect-continue handling is a problem depends on whether your targeted client applications uses expect-continue authentication or not.

I haven't researched this in too much detail yet, so I can't say with certainty which containers do transparent handling and whether or not it can be disabled, or what client applications require it.

Might be good if someone from Grizzly or Tomcat could comment on options for disabling the container handling.

Brad at Kademi
  • 1,300
  • 8
  • 7
  • Is there a "reference container" for Milton where expect-continue works out-of-the-box? I do not have to use Grizzly if I cannot make it work. – Thilo Dec 14 '11 at 00:03