HTTP Service

Release version: 1.1.2 - April 27, 2005 ( changes )

This bundle is an implementation of the OSGi HTTP Service, Version 1.1. It is built on top of an embedded version of Jetty. The Jetty version itself is not modified, however additional support classes are 'added' to the Jetty classes to make the integration work. These can be found on the org.mortbay.* sources included withing the HTTP bundle sources.

At this stage the implementation is believed to be largely compliant and supports both registering of servlets and resources by a bundle.

Currently, the HTTP service uses port 80 (which requires root permission) on the local host or at a configurable port as described below. If a bundle registers a servlet with alias /MyServlet, then the servlet will be accessible from http://localhost:80/MyServlet.

Richard S. Hall (
Rob Walker (


Relevant interface(s)
public interface HttpService
public void registerServlet(
String alias, Servlet servlet, Dictionary params, HttpContext context)
throws ServletException, NamespaceException;
public void registerResources(
String alias, String name, HttpContext context)
throws NamespaceException;
public void unregister(String alias);

public interface HttpContext
public boolean handleSecurity(
HttpServletRequest request, HttpServletResponse response)
throws IOException;
public URL getResource(String name);
public String getMimeType(String name);

The http bundle offers the following standard OSGi configurable properties:

The http bundle also offers the following Oscar specific configurable properties:

These properties can be configured using the standard file as described in the usage document.

HTTPS support
Basic HTTPS support is included using JSSE listener classes supplied in the Jetty bundle. These require a minimum of supporting infrastructure the main component of which is a keystore file with a valid certificate. The Jetty FAQs provide details on how to create these and a discussions of issues on their usage.

Note that in the current implementation passwords need to be provided either in the Oscar configuration files, the Oscar launch process via System properties, or by entry on the command line. These will only be secure if Oscar itself is being installed and run in a secure environment. Enhanced security would need additional work, possibly to include abstraction of the security provider and keystore aspects into modular services which could themselves be made secure.

An example and keystore file have been provided. The keystore file includes a certificate for localhost with both passwords set to password