Re: Strange results trying Jetty 6 version of Http service

[Rob Walker]

Signing off for the weekend - but will pick this up next week if no one else gets a chance. The good news - is if we can fix this in line with OSGi, I have the following working in the Http service layer: Last-Modified If-Modified-Since when checked in, this will now be automatic for for standard url and file resources e.g. GET /VtWebUi/js/ext/resources/css/ext-all.css HTTP/1.1 Accept: */* Referer: http://localhost:8084/VtWebUi/ Accept-Language: en-gb UA-CPU: x86 Accept-Encoding: gzip, deflate If-Modified-Since: Sun, 24 Feb 2008 18:48:14 GMT User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648) Host: localhost:8084 Connection: Keep-Alive Cookie: clickedFolderroot=1%5E2%5E; checkedFolderroot=38%5E38%5E ... HTTP/1.1 304 Not Modified Last-Modified: Sun, 24 Feb 2008 18:48:14 GMT Content-Type: text/css Server: Jetty(6.1.x) The performance benefits of these are huge, since they massively reduced I/O and CPU on the server side for client (or intermediate proxy) cached resources -- Rob Rob Walker wrote: Hmmm - some further clues that something may be amiss here:          //fails:          //srvHttp.registerResources(alias, "", myContext);          //srvHttp.registerResources(alias + logsAlias, "", this.envLogsContext);          //works:          srvHttp.registerResources(alias + logsAlias, "", this.envLogsContext);          srvHttp.registerResources(alias, "", myContext); Simply swapping the order of registration changes the behaviour , not quite to fully working - but a lot closer. I'm fairly sure the order of registration shouldn't change any behaviour, except in the case of a duplicate alias exception - which this isn't. The OSGi rules for walking back down a substring of aliases until there's a match aren't based on which got registered first Looking at the traces, Jetty seems to be using later registered aliases first - hence why the swap makes a difference. I suspect what is broken here is how Jetty does path matching to servlets - it doesn't look like it matches according to alias rules for OSGi in this newer Jetty version. -- Rob Rob Walker wrote: 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 -- 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