Funções do recurso Servlet 3.1
O WebSphere Application Server tradicional suporta a especificação do Servlet 3.1. Visualize os esclarecimentos e descrições de funções destacadas.

As descrições de todas as funções são fornecidas no Java Servlet Specification e não são descritas na documentação do produto. No entanto, mais considerações para a função do Servlet 3.1 são as seguintes:
newfeatE/S assíncrona
Um recurso do Servlet 3.1 que especifica que quando a leitura sem bloqueio é iniciada, qualquer recurso durante o tempo de vida de solicitação restante não pode chamar APIs, o que pode resultar em uma leitura bloqueada. Por exemplo, para uma solicitação de POST após o listener de leitura ser configurado pelo recurso, qualquer chamada subsequente para as APIs getParameter() e getPart() resultará em uma IllegalStateException.
Ao trabalhar com servlets assíncronos, configure o tempo limite com a API AsyncContext.setTimeout, caso contrário, o valor padrão do contêiner, como 30 segundos, será utilizado. O tempo limite é reconfigurado cada vez que async é iniciado usando o ServletRequest. A API StartAsync é chamada e expira quando a API AsyncContext.complete não é chamada dentro do período de tempo limite que segue o async iniciado pela última vez. Ao utilizar o suporte de E/S assíncrona que é fornecido, configure o valor de tempo limite com a API AsyncContext.setTimeout para permitir também que a E/S assíncrona seja concluída. A conclusão depende de outros factores externos, como o ambiente ou a velocidade da rede.
Processamento de upgrade
<webContainer upgradeReadTimeout="5000" />
<webContainer upgradeWriteTimeout="5000" />
A solicitação não deve ser atualizada utilizando o recurso de upgrade para Servlet 3.1 quando a solicitação estiver sendo manipulada pelo servlet assíncrono.
O aplicativo que suporta o recurso do Servlet 3.1 para upgrade requer que a conexão na solicitação permaneça aberta entre o cliente e o aplicativo que hospeda o upgrade. Se o aplicativo não iniciar o fechamento do WebConnection () quando o processamento de upgrade for concluído a partir de seu manipulador ou de quaisquer outros recursos, como ReadListener ou WriteListener, a conexão TCP permanecerá aberta até que o servidor ser reciclado.
Chamado quando todos os dados para a solicitação atual forem lidos.
No caso de Upgrade, o servidor não conhece o final dos dados, porque os dados atualizados não estão delimitados da maneira como os dados do corpo da solicitação de HTTP estão. A não ser quando a conexão do cliente for fechada, não há nenhuma determinação para o término dos dados.Autenticação baseada em formulário
Após a autenticação bem-sucedida, um cliente é redirecionado para o recurso da solicitação original. A especificação Servlet 3.1 especifica: "Para melhorar a previsibilidade do método de HTTP da solicitação redirecionada, os contêineres devem ser redirecionados usando o código de status 303 (SC_SEE_OTHER), exceto onde a interoperabilidade com agentes do usuário de HTTP 1.0 for necessária; nos casos em que o código de status 302 devam ser usados." O recurso Servlet 3.1 mantém a interoperabilidade com agentes do usuário de HTTP 1.0 e usa sempre o código de status 302. Para obter mais informações sobre como configurar o Servlet 3.1 para segurança, leia o tópico Configurando para o Servlet 3.1.
Dados grandes postados
A adição da API ServletRequest.getContentLengthLong() requer suporte para receber dados postados de um comprimento maior que Integer.MAX_VALUE e não podem ser integralmente acomodados em uma matriz de byte único ou sequência.
String getParamter(String name)
String[] getParameterValues()
Map<String,String> getParameterMap()
É possível enviar dados postados que contêm múltiplos parâmetros, que, quando combinados, terão um comprimento maior que Integer.MAX_VALUE. No entanto, cada nome de parâmetro individual e valor de parâmetro deve ser menor que Integer.MAX_VALUE em comprimento.
- Você deve enviar dados postados em chunks menores que Integer.MAX-VALUE em comprimento.
- Os dados de postados que são processados pelo contêiner da web, como parâmetros ou partes, devem ser lidos totalmente, antes do início do processamento. Os dados postados podem impor requisitos de memória significativos para dados postados grandes, porque eles poderão exigir o máximo de memória como o dobro do tamanho dos dados postados, para que o processamento do contêiner da web seja bem-sucedido.