Re: Strange results trying Jetty 6 version of Http service

[Rob Walker]

This looks definitely wrong to me in the current SVN rev, albeit our usage is a strange case that perhaps not many use, I think the new internal operation is wrong 102.4 of the R4 companion spec uses the following table to show mapping: We have a very similar example alias 1 - /VtWebUi alias 2 - /VtWebUi/logs To me - a request for /VtWebUi - should only get routed to the getResource of alias 1? I can't see any way according to the spec, the getResource of alias 2 should be called - it's not a matching substring, even if the getResource for alias 1 returned null (which it wouldn't in our case anyhow). -- Rob Rob Walker wrote: I haven't - will take a look if feasible. >From my earlier work in this area - I've a hunch this doesn't follow the spec! -- rob Stuart McCulloch wrote: 2008/10/10 Rob Walker <[EMAIL PROTECTED]>   Anyone else found strange results moving to the Jetty 6 version of Http? It totally breaks our implementation, and seems to be directing getResource() requests to odd (possibly wrong) resource handlers We have both of the following aliases mounted for resource serving:   * /VtWebUi - served by a "WebUiContext" class   * /VtWebUi/logs - served by a "LogsContext" class A request to   http://localhost:8084/VtWebUi is getting directed to the LogsContext class (which serves /VtWebUi/logs) - and the attached resource path is empty According to my understanding (and the previous Jetty 4 version) - this should get directed to the "WebUiContext" This feels broken to me - a "general" alias shouldn't get routed to a context class with a specific qualifier on the end which doesn't match?     have you tried the same test with Pax-Web?  Alin spent a lot of time making sure it followed the spec.   Regards -- Rob Ascert - Taking systems to the Edge [EMAIL PROTECTED] +44 (0)20 7488 3470 www.ascert.com       -- Ascert - Taking systems to the Edge [EMAIL PROTECTED] +44 (0)20 7488 3470 www.ascert.com