Fonctions du dispositif Servlet 3.1
WebSphere Application Server Traditional prend en charge la spécification Servlet 3.1. Consultez les explications et descriptions des fonctions mises en évidence.

Les descriptions de toutes les fonctions sont fournies dans Java Servlet Specification et ne sont pas décrites dans la documentation du produit. Toutefois la fonction Servlet 3.1 appelle certaines considérations :
newfeatE-S asynchrones
Une fonctionnalité de Servlet 3.1 indique que, lorsque la lecture non bloquante est démarrée, une ressource utilisée lors des demandes restantes ne peut pas appeler d'API, ce qui peut entraîner une lecture bloquante. Par exemple, pour une demande POST après la définition d'un programme d'écoute de lecture par la ressource, tous les résultats d'API getParameter() et getPart() suivants génèrent une exception IllegalStateException.
Lorsque vous utilisez des servlets asynchrones, définissez le délai d'attente à l'aide de l'API AsyncContext.setTimeout. Sinon, la valeur par défaut du conteneur, par exemple 30 secondes, sera utilisée. Le délai d'attente est réinitialisé chaque vois que le servlet asynchrone démarre en utilisant ServletRequest. L'API StartAsync est appelée et elle expire lorsque l'API AsyncContext.complete n'est pas appelée dans le délai qui suit le dernier démarrage des servlets asynchrones. Lorsque vous utilisez la prise en charge des E-S asynchrones fournie, définissez la valeur de délai à l'aide de l'API AsyncContext.setTimeout afin de permettre l'exécution des E-S asynchrones. L'exécution dépend d'autres facteurs externes, comme l'environnement ou la vitesse du réseau.
Processus de mise à niveau
<webContainer upgradeReadTimeout="5000" />
<webContainer upgradeWriteTimeout="5000" />
La demande ne doit pas être mise à niveau à l'aide de la fonction de mise à niveau pour Servlet 3.1 quand elle est gérée par servlet asynchrone.
L'application qui prend en charge la fonction Servlet 3.1 pour la mise à niveau nécessite que la connexion sur la demande reste ouverte entre le client et l'application qui héberge la mise à niveau; Si l'application n'initie pas la fermeture de WebConnection () quand le processus de mise à niveau est terminé, ce à partir de son gestionnaire ou de toute autre ressource, telle que ReadListener ou WriteListener, la connexion TCP reste ouverte jusqu'à ce que le serveur débute un nouveau cycle.
Invoked when all data for the current request is read.
Dans le cas de mise à jour, le serveur ne connaît pas la fin des
données car les données mises à jour ne sont pas délimitées de la
même manière que les données du corps de la demande HTTP. Outre le
moment de la fermeture de la connexion client, il n'y a aucune
détermination pour la fin des données.Authentification par formulaire
Après une authentification réussie, un client est redirigé vers la ressource de la demande d'origine. La spécification Servlet 3.1 indique que "pour améliorer le caractère prévisionnel de la méthode HTTP de la demande redirigée, les conteneurs doivent effectuer la redirection à l'aide du code d'état 303 (SC_SEE_OTHER), sauf quand l'interopérabilité avec des agents utilisateur HTTP 1.0 est requise, auxquels cas le code d'état 302 doit être utilisé." La fonction Servlet 3.1 conserve l'interopérabilité avec les agents utilisateur HTTP 1.0 et utilise toujours le code d'état 302. Pour plus d'informations sur la configuration de Servlet 3.1 pour la sécurité, reportez-vous à la rubrique Configuring for Servlet 3.1.
Données POST volumineuses
L'ajout de l'API ServletRequest.getContentLengthLong() requiert la prise en charge de la réception des données POST d'une longueur supérieure à Integer.MAX_VALUE et qui ne peuvent pas tenir complètement dans un tableau ou une chaîne simple octet.
String getParamter(String name)
String[] getParameterValues()
Map<String,String> getParameterMap()
Il est possible d'envoyer des données POST contenant plusieurs paramètres qui, lorsqu'elles sont combinées, ont une longueur supérieure à Integer.MAX_VALUE. Toutefois, chaque nom du paramètre individuel et chaque valeur de paramètre doit avoir une longueur inférieure à Integer.MAX_VALUE.
- Vous devez envoyer les données POST par blocs d'une longueur inférieure à Integer.MAX-VALUE .
- Les données POST qui sont traitées par le conteneur Web, comme les paramètres ou les composants, doivent être entièrement lues avant le début du traitement. Les données POST peuvent imposer des exigences significatives en termes de mémoire lorsqu'elles sont volumineuses. En effet, l'espace mémoire requis peut être le double de la taille des données POST pour que le conteneur Web puisse les traiter correctement.