felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Walker <r...@ascert.com>
Subject Re: Strange results trying Jetty 6 version of Http service
Date Fri, 10 Oct 2008 15:49:37 GMT
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 <robw@ascert.com>
>>>>
>>>>  
>>>>> 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
>>>>> robw@ascert.com
>>>>> +44 (0)20 7488 3470
>>>>> www.ascert.com
>>>>>
>>>>>     
>>>>
>>>>
>>>>
>>>>   
>>>
>>
>> -- 
>>
>>
>> Ascert - Taking systems to the Edge
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com
>
> -- 
>
>
> Ascert - Taking systems to the Edge
> robw@ascert.com
> +44 (0)20 7488 3470
> www.ascert.com

-- 


Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com


Mime
View raw message