Funciones de la característica Servlet 3.1

WebSphere® Application Server tradicional da soporte a la especificación Servlet 3.1 . Vea las clarificaciones y descripciones de las funciones resaltadas.

Las descripciones de todas las funciones se proporcionan en la Especificación de servlet Java y no se describen en la documentación del producto. Sin embargo, hay más consideraciones para la función Servlet 3.1 en las secciones siguientes:

Entrada/salida asíncrona

Una característica Servlet 3.1 que especifica que cuando se inicia la lectura sin bloqueo, cualquier recurso durante el tiempo de vida restante de la solicitud no puede llamar a las API, lo que puede dar como resultado una lectura de bloqueo. Por ejemplo, para una solicitud POST después de que el recurso establezca el escucha de lectura, cualquier llamada posterior a la API getParameter() y getPart() produce una IllegalStateException.

Cuando trabaje con servlets asíncronos, establezca el tiempo de espera con la API AsyncContext.setTimeout, de lo contrario se utilizará el valor predeterminado de contenedor, por ejemplo, 30 segundos. El tiempo de espera se restablece cada vez que se inicia la operación time async utilizando ServletRequest. La API StartAsync se llama y caduca cuando no se llama a la API AsyncContext.complete dentro del periodo de tiempo de espera después de que se haya iniciado asíncronamente por última vez. Cuando se utiliza el soporte de E/S asíncrona proporcionado, defina el valor de tiempo de espera con el API AsyncContext.setTimeout para permitir también que la E/S asíncrona se complete. La finalización depende de otros factores externos, como el entorno o la velocidad de la red.

Proceso de actualización

El proceso de actualización es una característica de Servlet 3.1 que no tiene capacidad de lectura y escritura de bloqueo. Cuando las operaciones de lectura y escritura son asíncronas, no hay ningún límite sobre cuánto tiempo espera el servidor a que se complete la operación. Puede establecer los tiempos de espera con las propiedades personalizadas del contenedor web en el archivo server.xml, como upgradereadtimeout y upgradewritetimeout. Consulte el ejemplo siguiente de un tiempo de espera de 5 segundos:
<webContainer upgradeReadTimeout="5000" />
<webContainer upgradeWriteTimeout="5000" />

La solicitud no se debe actualizar utilizando la característica de actualización para Servlet 3.1 cuando la solicitud está siendo manejada por un servlet asíncrono.

La aplicación que da soporte a la característica Servlet 3.1 para la actualización requiere que la conexión en la solicitud permanezca abierta entre el cliente y la aplicación que aloja la actualización. Si la aplicación no inicia el cierre de WebConnection () cuando el proceso de actualización se completa desde su manejador o cualquier otro recurso como, por ejemplo, ReadListener o WriteListener, la conexión TCP permanece abierta hasta que se recicla el servidor.

Cuando se utiliza un UpgradeHandler y un ReadListener de la función Servlet 3.1, el método ReadListener.onAllDataRead sólo se invoca cuando el cliente cierra la conexión con el servidor que aloja la aplicación actualizada. El Javadoc de onReadListener.onAllDataRead devuelve el siguiente mensaje:
Se invoca cuando se leen todos los datos
de la solicitud actual.
En el caso de actualización, el servidor no conoce el final de los datos porque los datos actualizados no está delimitados del mismo modo que los datos del cuerpo de la solicitud HTTP. Aparte de cuando se cierra la conexión de cliente, no hay ninguna determinación para el final de los datos.

Autenticación basada en formularios

Después de una autenticación satisfactoria, se redirige al cliente al recurso de la solicitud original. La especificación Servlet 3.1 especifica: Para mejorar la previsibilidad del método HTTP de la petición redirigida, los contenedores deben redirigir utilizando el código de estado 303 (SC_SEE_OTHER), excepto cuando se requiera la interoperabilidad con los agentes de usuario HTTP 1.0; en cuyo caso debe utilizarse el código de estado 302. La función Servlet 3.1 mantiene la interoperabilidad con los agentes de usuario HTTP 1.0 y utiliza siempre el código de estado 302. Para obtener más información sobre cómo configurar Servlet 3.1 para la seguridad, lea el tema Configuración para Servlet 3.1.

Datos de publicación grandes

La adición de la API ServletRequest.getContentLengthLong() requiere soporte para recibir datos de publicación de una longitud superior a Integer.MAX_VALUE y que pueden acomodarse por completo en una serie o matriz de un solo byte.

Esta adición tiene implicaciones cuando se obtiene contenido de datos de publicación que utiliza las API que devuelven contenido en una serie o byte []. Por ejemplo, los métodos javax.servlet.ServletRequest para acceder a los parámetros:
String    getParamter(String name)
String[]  getParameterValues()
Map<String,String> getParameterMap()

Es posible enviar datos de publicación que contengan varios parámetros que, al combinarse, tienen una longitud superior al valor especificado por Integer.MAX_VALUE. Sin embargo, la longitud de cada nombre de parámetro y valor de parámetro individual debe ser inferior a Integer.MAX_VALUE.

El envío de una gran cantidad de datos de publicación implica estas consideraciones adicionales:
  • Debe enviar los datos de publicación en fragmentos de menos de Integer.MAX-VALUE de longitud.
  • Los datos de publicación procesados por el contenedor web, como por ejemplo parámetros o partes, deben haberse leído totalmente antes de que se inicie el proceso. Los datos de publicación pueden imponer requisitos de memoria significativos para los datos de publicación de gran tamaño, ya que podrían requerir una memoria de hasta el doble del tamaño de los mismos para que el proceso de contenedor web sea satisfactorio.