[
https://issues.apache.org/jira/browse/FELIX-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638953#action_12638953
]
Rob Walker commented on FELIX-763:
----------------------------------
Agree that the earlier Jetty4 version didn't fully follow spec, but this is a
new error case - our original code worked fine against the Jetty4 version and
now totally breaks under the above. The Jetty4 version definitely didn't send
getResource requests to aliases that didn't match the base path, at least not
for the codebase / examples we have here.
Totally agree that it'd be nice if a TCK of some form existed to verify this
specific part.
> Jetty6 version of Http doesn't resolve aliases according to OSGi spec
> ---------------------------------------------------------------------
>
> Key: FELIX-763
> URL: https://issues.apache.org/jira/browse/FELIX-763
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
> Reporter: Rob Walker
>
> 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"
> ====
> Form further analysis:
> 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
> We have a very similar example to the table in 102.4 of the R4 companion
> spec.
> 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).
> ===
> Additional info:
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
