Skip navigation links

Package net.jini.jeri.http

Provides implementations of the Endpoint and ServerEndpoint abstractions that use HTTP messages sent over TCP sockets as the underlying communication mechanism.

See: Description

Package net.jini.jeri.http Description

Provides implementations of the Endpoint and ServerEndpoint abstractions that use HTTP messages sent over TCP sockets as the underlying communication mechanism. HttpEndpoint instances can be used by clients to initiate calls over HTTP; each instance contains the host name and TCP port number to which to connect, as well as an optional SocketFactory for customizing the type of Socket to use. HttpServerEndpoint instances are used to listen for and receive incoming calls over HTTP; each instance contains the name of the listening host and the number of the TCP port on which to listen, as well as an optional ServerSocketFactory for customizing the type of ServerSocket to use.

Note that providing socket factories which produce SSL sockets does not result in endpoints which are fully HTTPS capable. HTTPS support is offered by the net.jini.jeri.ssl security provider.

HTTP mapping

HttpEndpoint and HttpServerEndpoint map OutboundRequest and InboundRequest instances to HTTP request/response messages: request data is transmitted as the entity-body of an HTTP POST request, while response data is transmitted as the entity-body of the corresponding HTTP response message. When possible, HTTP 1.1 persistent connections and chunked transfer coding are employed. For information on HTTP, refer to RFC 2616.

HTTP proxying

To determine whether or not requests should be sent through an HTTP proxy, HttpEndpoint consults the same set of system properties used by HttpURLConnection: The values of the system properties above are resampled for each new outbound HTTP message.

HTTP authentication

HttpEndpoint supports both basic and digest HTTP authentication methods, specified in RFC 2617. Like HttpURLConnection, it obtains authentication parameters (e.g., username, password) from the Authenticator class.

Constraint support

HttpEndpoint and HttpServerEndpoint support the transport layer aspects of at least the following constraints: (Note that ClientMaxPrincipal, ClientMaxPrincipalType, ClientMinPrincipal, ClientMinPrincipalType, ServerMinPrincipal, DelegationAbsoluteTime, and DelegationRelativeTime constraints are trivially supported if ClientAuthentication.YES, ServerAuthentication.YES, and Delegation.YES are not supported.)
Since:
2.0
Version:
2.0
Implementation Specifics:

Logging

This implementation uses the Logger named net.jini.jeri.http.client to log information at the following levels:

Level Description
FAILED exceptions thrown attempting to initiate a request
HANDLED exceptions caught attempting to connect a socket, set options on a client-side socket, or reuse a connection
FINE client-side socket operations (create, connect, reuse, and close)

This implementation uses the Logger named net.jini.jeri.http.server to log information at the following levels:

Level Description
WARNING exceptions accepting on a server socket
HANDLED exceptions caught setting options on a server-side socket
FINE server-side socket operations (create, accept, and close)

System properties

In addition to the HTTP proxy-related system properties listed above, this implementation of HttpEndpoint and HttpServerEndpoint recognizes the following system properties:

  • org.apache.river.jeri.http.idleConnectionTimeout - The number of milliseconds to retain idle client-side HTTP connections before closing them. The default is 15000.
  • org.apache.river.jeri.http.idleServerConnectionTimeout - The number of milliseconds to retain idle server-side HTTP connections before closing them. The default is the idle client-side connection timeout (as specified by the org.apache.river.jeri.http.idleConnectionTimeout system property) plus 10000.
  • org.apache.river.jeri.http.responseAckTimeout - The number of milliseconds to wait for acknowledgments from AcknowledgmentSource instances. The default is 15000.
  • org.apache.river.jeri.http.disableProxyPersistentConnections - If the value is case-insensitive equal to true, client-side connections through the HTTP proxy are not reused across requests; otherwise, persistent connections are maintained and reused if possible.
  • org.apache.river.jeri.http.pingProxyConnections - If the value is case-insensitive equal to true, then if an HTTP proxy is being used, ping the server endpoint to verify whether it is alive and reachable. The ping occurs before the first request and before each subsequent request which follows the expiration of the ping proxy timeout period (below) following the previous ping. When using an HTTP proxy it is often impossible to distinguish between inability to reach the server endpoint (such as because the server process refused a connection by the HTTP proxy) and the lack of response from a delivered request (which might result in an UnmarshalException). The ping increases the likelihood that the inability to reach the server endpoint can be explicitly identified. The default value is false, and no pings are done.
  • org.apache.river.jeri.http.pingProxyConnectionTimeout - The number of milliseconds from the time a server endpoint was last pinged before a ping will precede the next request. The default is Long.MAX_VALUE (essentially meaning, ping only before the first request).
Skip navigation links

Copyright 2007-2013, multiple authors.
Licensed under the Apache License, Version 2.0, see the NOTICE file for attributions.