You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Rob Walker <ro...@ascert.com> on 2008/10/10 16:45:44 UTC
Strange results trying Jetty 6 version of Http service
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?
Regards
-- Rob
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Strange results trying Jetty 6 version of Http service
Posted by Rob Walker <ro...@ascert.com>.
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 <ro...@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
Re: Strange results trying Jetty 6 version of Http service
Posted by Rob Walker <ro...@ascert.com>.
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 <ro...@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
Re: Strange results trying Jetty 6 version of Http service
Posted by Rob Walker <ro...@ascert.com>.
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 <ro...@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
Re: Strange results trying Jetty 6 version of Http service
Posted by Rob Walker <ro...@ascert.com>.
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 <ro...@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
Re: Strange results trying Jetty 6 version of Http service
Posted by Stuart McCulloch <mc...@gmail.com>.
2008/10/10 Rob Walker <ro...@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
>
--
Cheers, Stuart