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 estas funciones se proporcionan en Java Servlet Specification y no se describen en la documentación del producto. Sin embargo, las consideraciones adicionales para la función Servlet 3.1 son las siguientes:
newfeatE/S asíncrona
Característica de Servlet 3.1 que especifica que cuando se inicia la lectura no de bloqueo, ningún recurso durante el tiempo de vida restante de la solicitud puede llamar a las API, lo que da 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.
Cuando trabaje con servlets asíncronos, establezca el tiempo de espera con la API AsyncContext.setTimeout; de lo contrario se utilizará el valor predeterminado del contenedor, por ejemplo, 30. El tiempo de espera se restablece cada vez que se inicia async utilizando ServletRequest. Se llama a la API StartAsync y caduca cuando no se llama a la API AsyncContext.complete durante el periodo de tiempo de espera que siga a la última vez que se inició async. Cuando se utiliza el soporte de E/S asíncrona proporcionado, establezca el valor de tiempo de espera con la API AsyncContext.setTimeout para que la E/S asíncrona se pueda completar. La finalización depende de otros factores externos, como el entorno o la velocidad de la red.
Proceso 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 el servidor asíncrono gestione la solicitud.
La aplicación que da soporte a la característica de Servlet 3.1 de 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 inicializa WebConnection close () 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 continúa abierta hasta que se recicla el servidor.
Invocado cuando se han leído todos los datos para la solicitud actual.
En el caso de actualización, el servidor no conoce el final de los datos porque los datos actualizados no están 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 formulario
Después de una autenticación satisfactoria, se redirige al cliente al recurso de la solicitud original. La especificación Servlet 3.1 indica: "Para mejorar la predictabilidad del método HTTP de la solicitud redireccionada, los contenedores deben redirigirse utilizando el código de estado 303 (SC_SEE_OTHER), excepto en los casos en los que se requiera la interoperatividad con agentes de usuario HTTP 1.0, en cuyo caso se debe utilizar el código de estado 302." La característica de Servlet 3.1 mantiene la interoperatividad con los agentes de usuario HTTP 1.0 y siempre utiliza 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 del 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.