Fonctionnalités de la fonction Servlet 3.1
La fonction Servlet 3.1 assure une prise en charge complète de la spécification Servlet 3.1.
Les nouvelles fonctionnalités de la fonction Servlet 3.1 ne sont pas intégralement décrites ici car leurs descriptions figurent dans la spécification Servlet 3.1. Voici cependant quelques remarques supplémentaires concernant la fonction Servlet 3.1 :
E/S asynchrones
Une nouvelle fonctionnalité de la fonction 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 des API, ce qui peut entraîner une lecture bloquante. Par exemple, pour qu'une demande POST après que le programme d'écoute de lecture soit définie par la ressource, tous les résultats d'API getParameter() et getPart() API suivants entraînent une exception IllegalStateException.
Vous devez tenir compte de la définition du délai d'attente avec l'API AsyncContext.setTimeout lorsque vous gérez des servlets async, sinon la valeur par défaut (par exemple, 30 secondes) est utilisée. Le délai d'attente est réinitialisé à chaque redémarrage des servlets async avec 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 async. Lorsque vous utilisez le support d'E-S async qui est fourni par la fonction Servlet-3.1, définissez la valeur de délai avec l'API AsyncContext.setTimeout afin d'autoriser également l'exécution des E-S async. L'exécution dépend d'autres facteurs externes, comme l'environnement ou la vitesse du réseau.
Traitement des mises à 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 lorsqu'elle est traitée par un servlet async.
L'application qui prend en charge la fonction Servlet 3.1 pour la mise à niveau implique que la connexion sur la demande mise à niveau demeure ouverte entre le client et l'application qui héberge la mise à niveau. Si l'application n'initie pas WebConnection close() une fois le traitement de la mise à niveau terminée depuis son gestionnaire ou d'autres ressources, comme ReadListener ou WriteListener, la connexion TCP demeure ouverte jusqu'au précycle du serveur.
Lorsque vous utilisez une ressource UpgradeHandler et ReadListener depuis la fonction Servlet 3.1, la méthode ReadListener.onAllDataRead est appelée uniquement lorsque le client ferme la connexion au serveur qui héberge l'application mise à jour. L'élément Javadoc de la méthode onReadListener.onAllDataRead indique "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 ce qui suit : "Afin d'améliorer le caractère prévisionnel de la méthode HTTP de la demande redirigée, les conteneurs doivent rediriger avec le code d'état 303 (SC_SEE_OTHER), excepté lorsque l'interopérabilité avec les agents utilisateur HTTP 1.0 est requise, auquel cas le code d'état 302 doit être utilisé." La fonction Servlet-3.1 maintient l'interopérabilité avec les agents utilisateur HTTP 1.0 et utilise systématiquement le code d'état 302. Pour plus d'informations sur la configuration du de Servlet 3.1 pour la sécurité, lisez la rubrique relative à la configuration du profil Liberty pour 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.