Hi Gunnar, Am 24.10.2012 um 14:20 schrieb Gunnar Wagenknecht: > Hi, > > I learned about ongoing work for updating the HttpService spec yesterday > at OSGi DevCon in a talk from Felix. Thanks a lot for those insights > into the ongoing spec work. > > There are a few things that I'd like to throw into the discussion that > may (or may not) be of interest when updating the HttpService spec.
Thanks for your interest. > > One think that might be interesting is to have the ability to control > which bundle (signer?) is allowed to register in which namespace. For > example, if there is an set of administrative component registering > things under /admin/... when I'd like to prevent other bundles in the > system to also register under that namespace. I could imagine we define Permissions that a bundle might require to register servlets and filters with patterns. From an implementations and configurations point of view, this is probably a simple solution. The drawback is, that it requires security to be turned on and the Conditional Permission Admin Service be deployed. > > Another thing is a clarification in the spec regarding the relation of > HttpContext and HttpSession. The Equinox HttpService currently uses the > HttpSession from the container for all registrations and all > HttpContext. Thus everybody shares the same session data. However, some > HttpService implementations create different sessions per context in the > underlying container. That only works if one can do a real deep > integration with the underlying container. However, the Equinox > ServletBridge just has one underlying session. Maybe a HttpContext can > define a prefix to session attribute keys (or something along the lines) > that scopes the session data to a particular HttpContext? I completely agree, that the spec has to be informative on how Http Sessions are handled same as the specification has to be clearer on how the API of the Servlet Context is implemented. My presentation proposed to share Http Sessions across all Servlet Contexts in a single Http Service. But I can understand that some deployments might want to have separate Http Session spaces. The problem, though, is that by default Http Session IDs are transferred using a cookie which is bound to the servlet context path of the respective web app. In the Http Service the servlet context path is the same for all servlets registered. That is all ServletContext instances maintained by the Http Service have the same context path. Thus all such contexts share the same session. One solution would maybe be to use the shared Http Session as a proxy session: This session is referred to in the cookie. But the attributes in the Session are the actual sessions, that are used by the respective Servlet Context. This would require the Http Service implementation to actually implement Session management. Maybe that makes perfect sense and the specification might have non-normative wording to propose such an implementation in addition to require Http Sessions to be managed per Servlet Context. Does this help ? Regards Felix > > -Gunnar > > -- > Gunnar Wagenknecht > gun...@wagenknecht.org > http://wagenknecht.org/ > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
