Community
Participate
Working Groups
After ContextHandler that was created from context XML file is moved to 'Deployed' node from 'Started' node by calling requestAppGoal() method of DeploymentManager, server continues to serve the content that belongs to the aforementioned context, despite the fact that context has been stopped that is confirmed by the following record in console log. 2011-03-03 18:20:29.421:INFO::stopped o.e.j.s.h.ContextHandler{/javadoc,file:/home/mgorovoy/code/eclipse/jetty7-trunk/jetty-distribution/target/distribution/javadoc}
This issue was caused by two contexts serving same context path, that caused the second context to take over when the first context was stopped.
I am reopening this for discussion.. I think we should have a mechanism that detects these sorts of context overloading, we could keep the default mode as it is but it would be good to have a flag on Server or in the handler chain somewhere that enables a 'strict' mode where the server will fail to start should there be a context overload situation.. thoughts?
This issue could potentially have security repercussions as a malicious app could potentially overlap a context path inside a legitimate app. There are several potential ways to resolve this issue, that are listed below. * Enhance the StandardDeployer binding in DeploymentManager infrastructure to (optionally) check a context path of each application that is being deployed against context paths handled by applications that had already been deployed. If an overlapping context path has been found, it will cause the binding to fail, and the offending application would not reach Deployed state. This approach will work only for web applications that are deployed via DeploymentManager. It will require special handling for the application that is deployed at root context path. It will also require keeping the reference to the contexts that have already been checked. It should be possible to implement this by creating back-door access to the DeploymentManager app queue. * Implement the validation of context paths as outlined above inside the Server class, and (optionally) execute it then the server is being started. This will have an advantage of being able to validate all context paths, rather when just the ones defined for web applications that are deployed through DeploymentManager. This will require a mechanism to be developed to validate contexts that are deployed dynamically after the server has been started. In any of the above scenarios, it would be necessary to develop a mechanism to determine whether an overlap is legitimate (e.g. context /foo overlapping the root context where root context doesn't have any handler for context path /foo). This will require developing a facility in ScopedHandler sub-classes that will allow traversing the chain of handlers and determining whether this chain has a handler that handles the specific context path.
On Tue, Mar 15, 2011 at 5:30 PM, Greg Wilkins <gregw@intalio.com> wrote: note that there are legitimate reasons for overlapping context paths. Virtual hosts and named connectors are both reasons that a context with a matching context path may not handle a request and allow it to fall through to another context. So the first challenge is detecting an overlap without false positives. But checking virtual paths should get 99.9% of cases. The we need to decide what to do in the case of an overlap: + Should we stop the old, then deploy the new? But that could lose some requests? + Should we start the new then stop the old? But that would mean we can't easily migrate sessions + Should we provide some session migration assistance? Whatever we decide, I think this is an issue to be dealt with by the deployers. So starting with a binding that detects overlap and warns about it would be a start. We can then think about how easy (or hard) it would to provide additional bindings to implement various policies.
I'm of the opinion that there is not much we can do here. The 50% case is that overlaps should not be done The 40% case is that overlaps are there for virtual hosts The 9% case is that overlaps are partial and for partitioning URI space The 1% case is that overlaps are for special reasons to do with hosts, redeployment etc. etc. I do not think we can find a one-size-fits all solution that covers all of these. Maybe we should simply put out info statements when we deploy that note any overlaps... but note that the root context will "overlap" all other contexts, so we have to be concerned about being tooo verbose. So I'm really inclined just to close this one.
closing as won't fix...greg makes a good point with the overlap notifications, maybe something in the future with deployers can be made more intelligent in this area but for now I am fine with closing this down for the time being
