Fonctionnalités de la fonction Servlet 3.1

Le produit prend en charge la spécification Servlet 3.1. Consultez les clarifications et les descriptions des fonctions disponibles.

Les descriptions des fonctions Servlet 3.1 sont fournies dans le document Java™ Servlet Specification et ne sont pas reprises dans la documentation du produit. Considérations supplémentaires pour les fonctions Servlet 3.1 :

E/S asynchrones

Une nouvelle caractéristique de la fonction Servlet 3.1 spécifie que lorsque la lecture non bloquante est démarrée, aucune ressource ne peut appeler des API pendant la durée de vie restante de la demande, 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 fois que qu'un servlet asynchrone est démarré 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

Important : Utilisez la classe ServletOutputStream avec l'interface WriteListener et la classe ServletInputStream avec l'interface ReadListener. N'utilisez pas ces classes avec la classe ObjectInputStream ou la classe ObjectOutputStream. Ces classes contournent certaines vérifications obligatoires des interfaces ReadListener et WriteListener, notamment les vérifications isReady, et peuvent entraîner un comportement inattendu.
Le traitement des mises à niveau est une fonction Servlet 3.1 avec capacité de lecture et d'écriture non bloquante. Lorsque les opérations de lecture et d'écriture sont asynchrones, l'attente par le serveur de l'achèvement de l'opération n'est pas plafonnée. Vous pouvez définir les délais à l'aide des propriétés personnalisées de conteneur Web dans le fichier server.xml, telles que upgradereadtimeout et upgradewritetimeout. Examinez l'exemple suivant de durée d'attente de 5 secondes :
<webContainer upgradeReadTimeout="5000" />
<webContainer upgradeWriteTimeout="5000" />

Lorsque la requête est traitée par un servlet asynchrone, elle ne doit pas être mise à niveau via la fonction de mise à niveau pour Servlet 3.1.

L'application qui prend en charge la fonction Servlet 3.1 pour mise à niveau nécessite que la connexion pour la requête reste ouverte entre le client et l'application qui héberge la mise à niveau. Si l'application n'initie pas l'opération WebConnection close () lorsque le traitement de la mise à niveau est terminé depuis son gestionnaire ou d'autres ressources, comme ReadListener ou WriteListener, la connexion reste ouverte jusqu'au prochain cycle serveur.

Lorsque vous utilisez une ressource UpgradeHandler et ReadListener depuis la fonction Servlet 3.1, la méthode ReadListener.onAllDataRead n'est appelée que quand le client ferme la connexion au serveur qui héberge l'application mise à niveau. Javadoc for onReadListener.onAllDataRead renvoie le message suivant :
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 stipule : Pour améliorer la prévisibilité de la méthode HTTP de la requête redirigée, les conteneurs doivent rediriger avec le code d'état 303 (SC_SEE_OTHER), sauf lorsque une interopérabilité avec les agents utilisateur HTTP 1.0 est requise (auquel cas le code d'état 302 doit être utilisé). La fonction 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 de Servlet 3.1 pour la sécurité, consultez la rubrique Configuration de 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.

Cet ajout a des implications si vous obtenez les données POST utilisant des API qui renvoient du contenu sous forme de chaîne ou d'octet[]. C'est le cas, par exemple, des méthodes javax.servlet.ServletRequest pour l'accès aux paramètres :
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.

Lors de l'envoi de gros volumes de données POST, vous devez tenir compte des considérations supplémentaires suivantes :
  • 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.

Icône indiquant le type de rubrique Rubrique de concept

Nom du fichier : cwlp_servlet31.html