Funktionen des Features Servlet 3.1
WebSphere Application Server Traditional unterstützt die Spezifikation Servlet 3.1. Sehen Sie sich die Erläuterungen und Beschreibungen hervorgehobener Funktionen an.

Die Produktdokumentation enthält nicht Beschreibungen aller in Java Servlet Specification bereitgestellter Funktionen. Im Folgenden finden Sie aber Überlegungen zur Servlet 3.1-Funktion:
newfeatAsynchrone Ein-/Ausgabe
Ein Servlet 3.1-Feature, das angibt, dass beim Start eines nicht blockierenden Lesevorgangs keine Ressource während der verbleibenden Laufzeit APIs aufrufen kann, was dazu führen kann, dass ein Lesevorgang blockiert wird. Wenn beispielsweise eine POST-Anforderung ausgeführt wird, nachdem der Listener für Lesevorgänge von der Ressource festgelegt wurde, lösen alle späteren Aufrufe der APIs getParameter() und getPart() eine Ausnahme des Typs IllegalStateException aus.
Wenn Sie mit asynchronen Servlets arbeiten, legen Sie das Zeitlimit mit der API AsyncContext.setTimeout fest. Andernfalls wird der Standardwert des Containers, z. B. 30 Sekunden, verwendet. Das Zeitlimit wird jedes Mal, wenn ein asynchrones Servlet mit ServletRequest gestartet wird, zurückgesetzt. Die API StartAsync wird aufgerufen und läuft ab, wenn die API AsyncContext.complete nicht innerhalb des Zeitlimitintervalls, das auf den letzten Start des asynchronen Servlets folgt, aufgerufen wird. Wenn Sie die bereitgestellte Unterstützung für asynchrone Ein-/Ausgabe nutzen, legen Sie den Zeitlimitwert mit der API AsyncContext.setTimeout so fest, dass die asynchrone Ein-/Ausgabe abgeschlossen werden kann. Dies hängt von anderen externen Faktoren ab, wie Umgebung oder Netzgeschwindigkeit.
Upgradeverarbeitung
<webContainer upgradeReadTimeout="5000" />
<webContainer upgradeWriteTimeout="5000" />
Für die Anforderung darf kein Upgrade mit dem Servlet 3.1-Upgradefeature durchgeführt werden, wenn die Anforderung von einem asynchronen Servlet verarbeitet wird.
Die Anwendung, die das Servlet 3.1-Upgradefeature unterstützt, setzt voraus, dass die Verbindung für die Anforderung zwischen dem Client und der Anwendung, die das Upgrade hostet, geöffnet bleibt. Wenn die Anwendung nach Abschluss des Upgradeprozesses keine Methode des Typs "WebConnection close()" über ihren Handler oder andere Ressourcen wie ReadListener oder WriteListener initiiert, bleibt die TCP-Verbindung geöffnet, bis der Server gestoppt und erneut gestartet wird.
Wird aufgerufen, wenn alle Daten für die aktuelle Anforderung gelesen wurden.
Wird ein Upgrade durchgeführt, kennt
der Server das Ende der Daten nicht, weil die aktualisierten Daten nicht in der Art und Weise mit Begrenzern versehen werden wie die Daten des Hauptteils der HTTP-Anforderung. Abgesehen
von dem Zeitpunkt, zu dem die Clientverbindung geschlossen wird, gibt es keine Begrenzung für das Datenende. Formularbasierte Authentifizierung
Nach erfolgreicher Authentifizierung wird ein Client an die Ressource der ursprünglichen Anforderung umgeleitet. Die Servlet 3.1-Spezifikation gibt dazu sinngemäß Folgendes an: "Um die Voraussagbarkeit der HTTP-Methode der umgeleiteten Anforderung zu verbessern, müssen Container Umleitungen mit dem Statuscode 303 (SC_SEE_OTHER) durchführen. Dies gilt nicht, wenn die Interoperabilität mit HTTP 1.0-Benutzeragenten erforderlich ist. In diesem Fall muss der Statuscode 302 verwendet werden." Das Feature Servlet 3.1 erhält die Interoperabilität mit HTTP 1.0.-Benutzeragenten aufrecht und verwendet immer den Statuscode 302. Weitere Informationen zur Sicherheitskonfiguration für Servlet 3.1 finden Sie unter "Konfiguration für Servlet 3.1 durchführen".
Umfangreiche Post-Daten
Das Hinzufügen der API ServletRequest.getContentLengthLong() erfordert Unterstützung für das Empfangen von Post-Daten mit einer Länge, die den Wert von Integer.MAX_VALUE überschreitet, und kann in einem Single-Byte-Array oder einer Zeichenfolge nicht vollständig umgesetzt werden.
String getParamter(String name)
String[] getParameterValues()
Map<String,String> getParameterMap()
Es ist möglich, Post-Daten mit mehreren Parametern zu senden, die, wenn sie kombiniert werden, eine Länge haben, die den Wert von Integer.MAX_VALUE überschreitet. Allerdings muss jeder einzelne Parametername und Parameterwert kleiner als Integer.MAX_VALUE sein.
- Sie müssen Post-Daten in Blöcken senden, die kleiner als Integer.MAX-VALUE sind.
- Post-Daten, die vom Web-Container verarbeitet werden, wie z. B. Parameter oder Abschnitte, müssen vor der Verarbeitung vollständig gelesen werden. Damit die Verarbeitung durch den Web-Container erfolgreich ist, muss für die Post-Daten ein erheblicher Speicherbedarf berücksichtigt werden, der doppelt so groß sein kann wie der eigentliche Umfang der Daten.