Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Gyrex/Concepts/Http Applications"

 
Line 1: Line 1:
The OSGi HTTP service allows registering servlets and resources which can then be accessed over HTTP. The CloudFree Platform makes heavy use of the OSGi HTTP service. All offered services are made available over HTTP. Additionally, an admin interface will be provided which can also be accessed over HTTP(S). In order to support good flexibility and scalable operation the concept of HTTP applications was created. This article describes the concept.
+
The OSGi HTTP service allows registering servlets and resources which can then be accessed over HTTP. Gyrex makes heavy use of the OSGi HTTP service. All offered services are made available over HTTP. Additionally, an admin interface will be provided which can also be accessed over HTTP(S). In order to support good flexibility and scalable operation the concept of HTTP applications was created. This article describes the concept.
  
  
 
== HTTP Applications ==
 
== HTTP Applications ==
  
The CloudFree Platform allows the definition of HTTP applications.
+
Gyrex allows the definition of HTTP applications.
 
Applications may be defined programmatically using an OSGi service or
 
Applications may be defined programmatically using an OSGi service or
 
in a declarative way using the Equinox extension registry to support
 
in a declarative way using the Equinox extension registry to support
Line 11: Line 11:
 
Technically speaking, a HTTP application is a collection of servlets  
 
Technically speaking, a HTTP application is a collection of servlets  
 
and resources. The main advantage compared to dealing with the OSGi  
 
and resources. The main advantage compared to dealing with the OSGi  
HTTP Service directly is that CloudFree HTTP applications define  
+
HTTP Service directly is that Gyrex HTTP applications define  
 
their own URL space. Thus, servlets and resources are not mounted
 
their own URL space. Thus, servlets and resources are not mounted
 
directly into the global namespace but into the namespace of the  
 
directly into the global namespace but into the namespace of the  
Line 26: Line 26:
 
== Mount Points ==
 
== Mount Points ==
  
The CloudFree Platform offers applications which run in a  
+
Gyrex offers applications which run in a  
 
tenant-specific context. Thus, multiple instances of the same  
 
tenant-specific context. Thus, multiple instances of the same  
 
application may be running. Each instance may expose differences in its  
 
application may be running. Each instance may expose differences in its  
Line 36: Line 36:
 
A mount is the binding of an URL to an application instance. The URL  
 
A mount is the binding of an URL to an application instance. The URL  
 
typically consists of a protocol, domain name, port and a path (eg.  
 
typically consists of a protocol, domain name, port and a path (eg.  
http://shop.cloudfree.net/admin/). Path and port may be optional. If no path  
+
http://shop.somedomain.com/admin/). Path and port may be optional. If no path  
 
is provided, the "root" path (i.e. "/") will be used. If no specific port is
 
is provided, the "root" path (i.e. "/") will be used. If no specific port is
 
provided, it will accept all ports. Everything below a mount point is  
 
provided, it will accept all ports. Everything below a mount point is  
Line 47: Line 47:
 
the contents of the transmission.  
 
the contents of the transmission.  
  
The CloudFree Platform will analyze incoming HTTP requests to read the  
+
Gyrex will analyze incoming HTTP requests to read the  
 
protocol, domain name, port and the path for discovering the application  
 
protocol, domain name, port and the path for discovering the application  
 
instance bound to a specific context. The path matching will happen after domain  
 
instance bound to a specific context. The path matching will happen after domain  
Line 55: Line 55:
 
For domain names, a suffix matching will be applied. This allows to  
 
For domain names, a suffix matching will be applied. This allows to  
 
capture requests to sub-domains. The longest matching domain wins.
 
capture requests to sub-domains. The longest matching domain wins.
For example, an application mount to "shop.cloudfree.net" will also  
+
For example, an application mount to "shop.somedomain.com" will also  
receive requests to the "www.shop.cloudfree.net" sub-domain if there  
+
receive requests to the "www.shop.somedomain.com" sub-domain if there  
 
is no other application mounted to that sub-domain.
 
is no other application mounted to that sub-domain.
  
A network operator must ensure that all requests targeted at a CloudFree
+
A network operator must ensure that all requests targeted at a HTTP
application instance will reach the CloudFree Platform. A network operator  
+
application instance will reach the Gyrex cluster. A network operator  
 
must also ensure that confidential guarantees are preserved when routing  
 
must also ensure that confidential guarantees are preserved when routing  
the request to the CloudFree Platform.  
+
the request to the Gyrex cluster.  
  
  
Line 69: Line 69:
 
=== HTTP Headers ===
 
=== HTTP Headers ===
  
The CloudFree platform may support HTTP headers which allow to specify  
+
Gyrex may support HTTP headers which allow to specify  
the original incoming URL if any system in front of the CloudFree
+
the original incoming URL if any system in front of Gyrex
Platform does not allow passing the original request. The following  
+
does not allow passing the original request. The following  
 
headers shall be supported.  
 
headers shall be supported.  
  
* <code>X-CloudFree-OriginalURL</code>
+
* <code>X-Gyrex-OriginalURL</code>
* <code>X-CloudFree-ClientIP</code>
+
* <code>X-Gyrex-ClientIP</code>
* <code>X-CloudFree-Key</code>
+
* <code>X-Gyrex-Key</code>
  
<code>X-CloudFree-OriginalURL</code> .. the original, complete URL.  
+
<code>X-Gyrex-OriginalURL</code> .. the original, complete URL.  
  
<code>X-CloudFree-ClientIP</code> .. the IP address of the client.  
+
<code>X-Gyrex-ClientIP</code> .. the IP address of the client.  
  
<code>X-CloudFree-Key</code> .. the key which identifies the source submitting the  
+
<code>X-Gyrex-Key</code> .. the key which identifies the source submitting the  
HTTP header. If no key or an invalid key is provided, the CloudFree
+
HTTP header. If no key or an invalid key is provided, Gyrex may reject the request or ignore the headers.
Platform may reject the request or ignore the headers.
+
  
  
 
=== HTTP Service Scenarios ===
 
=== HTTP Service Scenarios ===
  
The CloudFree Platform will support the following HTTP Service  
+
Gyrex will support the following HTTP Service  
 
scenarios.  
 
scenarios.  
  
Line 106: Line 105:
 
the service instance. The request handler is registered at the root  
 
the service instance. The request handler is registered at the root  
 
alias. It is also assumed that the service may be used exclusively by  
 
alias. It is also assumed that the service may be used exclusively by  
the CloudFree Platform. However, this assumption is not strictly
+
Gyrex. However, this assumption is not strictly
 
enforced.
 
enforced.
  
The CloudFree Platform may support the administration/configuration of  
+
Gyrex may support the administration/configuration of  
 
HTTP Services using very specific service implementations (eg. the  
 
HTTP Services using very specific service implementations (eg. the  
 
Equinox Jetty based HTTP Service). It may also possible to offer a very
 
Equinox Jetty based HTTP Service). It may also possible to offer a very
Line 124: Line 123:
 
more related to service administration and may not even touch the  
 
more related to service administration and may not even touch the  
 
platform if a third-party system (eg. SSL Accelerator proxy) is placed in front  
 
platform if a third-party system (eg. SSL Accelerator proxy) is placed in front  
of the CloudFree Platform to handle the issue. However, the CloudFree platform
+
of Gyrex to handle the issue. However, Gyrex
 
will support the integration with those systems to assist network
 
will support the integration with those systems to assist network
 
operators with the operation in those environments.
 
operators with the operation in those environments.

Latest revision as of 13:53, 21 July 2015

The OSGi HTTP service allows registering servlets and resources which can then be accessed over HTTP. Gyrex makes heavy use of the OSGi HTTP service. All offered services are made available over HTTP. Additionally, an admin interface will be provided which can also be accessed over HTTP(S). In order to support good flexibility and scalable operation the concept of HTTP applications was created. This article describes the concept.


HTTP Applications

Gyrex allows the definition of HTTP applications. Applications may be defined programmatically using an OSGi service or in a declarative way using the Equinox extension registry to support lazy loading of applications and their resources.

Technically speaking, a HTTP application is a collection of servlets and resources. The main advantage compared to dealing with the OSGi HTTP Service directly is that Gyrex HTTP applications define their own URL space. Thus, servlets and resources are not mounted directly into the global namespace but into the namespace of the application.

Applications operate in a tenant-specific context. A separate instances of an application will be created per context. This allows operating multiple versions of the same application in parallel. For example, each tenant can run its own version and a tenant can also run different instances to allow concepts like staging/production.


Mount Points

Gyrex offers applications which run in a tenant-specific context. Thus, multiple instances of the same application may be running. Each instance may expose differences in its behavior and functionality depending on the context it is running in. When a HTTP request is received the platform must be able to quickly detect (a) the application and (b) the context. In order to achieve this, the concept of mounts will be used.

A mount is the binding of an URL to an application instance. The URL typically consists of a protocol, domain name, port and a path (eg. http://shop.somedomain.com/admin/). Path and port may be optional. If no path is provided, the "root" path (i.e. "/") will be used. If no specific port is provided, it will accept all ports. Everything below a mount point is intended to be controlled by the application. The allowed URL protocols are http and https.

An application typically consists of two mount points – a confidential and a non-confidential mount point. The confidential mount point guarantees that data be transmitted so as to prevent other entities from observing the contents of the transmission.

Gyrex will analyze incoming HTTP requests to read the protocol, domain name, port and the path for discovering the application instance bound to a specific context. The path matching will happen after domain matching. A prefix matching is applied following the behavior of the HTTP Service specification.

For domain names, a suffix matching will be applied. This allows to capture requests to sub-domains. The longest matching domain wins. For example, an application mount to "shop.somedomain.com" will also receive requests to the "www.shop.somedomain.com" sub-domain if there is no other application mounted to that sub-domain.

A network operator must ensure that all requests targeted at a HTTP application instance will reach the Gyrex cluster. A network operator must also ensure that confidential guarantees are preserved when routing the request to the Gyrex cluster.


HTTP Integration

HTTP Headers

Gyrex may support HTTP headers which allow to specify the original incoming URL if any system in front of Gyrex does not allow passing the original request. The following headers shall be supported.

  • X-Gyrex-OriginalURL
  • X-Gyrex-ClientIP
  • X-Gyrex-Key

X-Gyrex-OriginalURL .. the original, complete URL.

X-Gyrex-ClientIP .. the IP address of the client.

X-Gyrex-Key .. the key which identifies the source submitting the HTTP header. If no key or an invalid key is provided, Gyrex may reject the request or ignore the headers.


HTTP Service Scenarios

Gyrex will support the following HTTP Service scenarios.

  • Single HTTP Service
  • Multiple HTTP Services

Single HTTP Service .. a single HTTP Service instance is running and receiving all requests (eg. Servlet Bridge or single Jetty instance).

Multiple HTTP Services .. multiple HTTP Service instances are running and each instance is receiving a specific set of requests (eg. HTTPS for different domains). Typically, this scenario may be used to provide better encapsulation between different contexts.

In both scenarios a single request handling servlet is registered with the service instance. The request handler is registered at the root alias. It is also assumed that the service may be used exclusively by Gyrex. However, this assumption is not strictly enforced.

Gyrex may support the administration/configuration of HTTP Services using very specific service implementations (eg. the Equinox Jetty based HTTP Service). It may also possible to offer a very deep integration with HTTP containers for best performance. However, it’s out of scope of this document to describe such implementation details.


HTTPS

The main issue with TLS/SSL is that it requires a channel (separate IP/port combination) for each domain. This makes administration not easier. Only recommendations can be given at this time. For example, to make things easier wildcard certificates may be used. But this topic is more related to service administration and may not even touch the platform if a third-party system (eg. SSL Accelerator proxy) is placed in front of Gyrex to handle the issue. However, Gyrex will support the integration with those systems to assist network operators with the operation in those environments.


HTTP Session

The final goal is to provide complete session isolation between applications. An extensible session manager will allow to provide application specific session handling. For example, one application may want to persist session state into a repository. Another application may not need sessions at all for scalability purposes.

Back to the top