Funktionen des Features Servlet 3.1
Das Feature Servlet 3.1 bietet vollständige Unterstützung für die Servlet 3.1-Spezifikation.
Die neuen Servlet 3.1-Funktionen sind in der Servlet 3.1-Spezifikation beschrieben und werden hier nicht erläutert. Es sind jedoch folgende zusätzliche Hinweise für das Feature Servlet 3.1 zu beachten:
Asynchrone Ein-/Ausgabe
Eine neue Funktion des Features Servlet 3.1 zeigt an, 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 bei einer POST-Anforderung die APIs getParameter() und getPart() aufgerufen werden, nachdem der Lesevorgangslistener von der Ressource festgelegt wurde, wird eine Ausnahme des Typs IllegalStateException ausgelöst.
Wenn Sie mit asynchronen Servlets arbeiten, müssen Sie mit der API AsyncContext.setTimeout ein Zeitlimit festlegen, da sonst Containerstandardwert (z. B. 30 Sekunden) verwendet wird. 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 Unterstützung für asynchrone Ein-/Ausgabe, die vom Feature Servlet 3.1 bereitgestellt wird, nutzen, setzen Sie den Zeitlimitwert mit der API AsyncContext.setTimeout, damit die asynchrone Ein-/Ausgabe fertiggestellt werden kann. Die Fertigstellung hängt von anderen externen Faktoren, wie Umgebung oder Netzgeschwindigkeit, ab.
Handhabung von Upgrades
<webContainer upgradeReadTimeout="5000" />
<webContainer upgradeWriteTimeout="5000" />
Für die Anforderung darf kein Upgrade mit der Servlet 3.1-Upgradefunktion durchgeführt werden, wenn die Anforderung von einem asynchronen Servlet verarbeitet wird.
Die Anwendung, die die Servlet 3.1-Upgradefunktion unterstützt,setzt voraus, dass die Verbindung für die aktualisierte Anforderung zwischen dem Client und der Anwendung, die den Upgrade hostet, geöffnet bleibt. Wenn die Anwendung nach Abschluss des Upgradeprozesses kein 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.
Wenn Sie einen UpgradeHandler und einen ReadListener über das Feature Servlet 3.1 verwenden, wird die Methode ReadListener.onAllDataRead nur aufgerufen, wenn der Client die Verbindung zu dem Server, der die aktualisierte Anwendung hostet, schließt. Die Javadoc für onReadListener.onAllDataRead gibt dazu sinngemäß Folgendes an: "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, sollten 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, dann sollte 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 "Liberty-Profil für Servlet 3.1 konfigurieren".
Umfangreiche Post-Daten
Die Hinzufügung der APIServletRequest.getContentLengthLong() erfordert Unterstützung für das Empfangen von Post-Daten mit einer Länge größer als Integer.MAX_VALUE 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 größer als Integer.MAX_VALUE haben. Allerdings muss jeder einzelne Parametername und Parameterwert kleiner als sein Integer.MAX_VALUE.
- 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.