Funciones de la característica Servlet 3.1
La característica Servlet 3.1 proporciona soporte completo para la especificación Servlet 3.1.
Las descripciones de las nuevas funciones de Servlet 3.1 se proporcionan en la especificación Servlet 3.1 y no se describen aquí. Sin embargo, las consideraciones adicionales para la característica Servlet 3.1 son las siguientes:
Entrada/salida asíncrona
Una nueva función de la característica Servlet 3.1 especifica que, cuando se inicia la lectura sin bloqueo, ningún recurso durante el ciclo de vida de solicitud restante puede llamar a las API, lo cual 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 subsiguiente a las API getParameter() y getPart() da como resultado una IllegalStateException.
Debe considerar la posibilidad de establecer el tiempo de espera con la API AsyncContext.setTimeout cuando trabaje con servlets asíncronos; de lo contrario, se utilizará el valor predeterminado del contenedor (por ejemplo, 30 segundos). El tiempo de espera se restablece cada vez que se inicia el proceso asíncrono utilizando ServletRequest. La API StartAsync se invoca y caduca cuando no se llama a la API AsyncContext.complete dentro del periodo de tiempo de espera que sigue a la última vez que se inició el proceso asíncrono. Cuando se utiliza el soporte de E/S asíncrona que proporciona la característica Servlet-3.1, establezca el valor de tiempo de espera con la 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.
Manejo de actualización
<webContainer upgradeReadTimeout="5000" />
<webContainer upgradeWriteTimeout="5000" />
La solicitud no se debe actualizar mediante la característica de actualización de Servlet 3.1 cuando la solicitud está siendo manejada por el 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 de la solicitud actualizada permanezca abierta entre el cliente y la aplicación que aloja la actualización. Si la aplicación no inicia WebConnection close() cuando el proceso de actualización se ha completado desde su manejador o cualquier otro recurso, como por ejemplo ReadListener o WriteListener, la conexión TCP permanece abierta hasta que el servidor se reinicia.
Cuando se utiliza un UpgradeHandler y un ReadListener de la característica Servlet 3.1, el método ReadListener.onAllDataRead sólo se invoca cuando el cliente cierra la conexión con el servidor que alberga la aplicación actualizada. El Javadoc de onReadListener.onAllDataRead indica que "Se invoca cuando se han leído 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 solicitud redirigida, los contenedores deben redirigirse utilizando el código de estado 303 (SC_SEE_OTHER), excepto cuando se requiera interoperatividad con agentes de usuario HTTP 1.0; en tales casos, debe utilizarse el código de estado 302." La característica Servlet-3.1 mantiene la interoperatividad con agentes de usuario HTTP 1.0 y utiliza siempre el código de estado 302. Para obtener más información sobre la configuración de Servlet 3.1 para la seguridad, consulte el tema Configuración del perfil Liberty 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.
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.
- 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.