Spring Boot 3.4.2: ContentCachingRequestWrapper gibt einen erschöpften InputStream zurück, nachdem das Anforderungskörpe ⇐ Java

[Anonymous]

Ich arbeite an einer Spring -Boot -Anwendung (3.4.2), in der ich ContentCachingRequestWrapper verwende, um mehrere Lesevorgänge der Anforderungsbehörde zu ermöglichen. Ich stoße jedoch auf ein Problem, bei dem nach dem Anforderungskörper einmal (z. B. durch einen Filter oder Interceptor) gelesen wurde, alle nachfolgenden Lesevorgänge geben einen leeren Stream zurück (read () == -1).
Was passiert? > [*] Eine frühere Komponente (in meinem Fall, ein Vorhandler, der die Anfrage zur Bestimmung des Typs analysiert) liest die Körper https://www.baeldung.com/spring-reading ... iple-times)
Later on in the filter chain, when Spring is attempting to do readWithMessageConverters, it creates an EmptyBodyCheckingHttpInputMessage , was wiederum einen Anruf beantragt. Dies gibt -1 zurück, was dazu führt, dass die nachfolgende Logik scheitert, da der Körper null ist, und eine nachfolgende Ausnahme von httpMessagenotreadable. >
< /ul>
public ServletInputStream getInputStream() throws IOException {
if (this.inputStream == null) {
this.inputStream = new ContentCachingInputStream(getRequest().getInputStream());
}
return this.inputStream;
}
< /code>
Da InputStream nach dem ersten Lesen im früheren Vorhandler nicht null ist, gibt Spring den gleichen (jetzt erschöpften) Stream zurück, anstatt eine neue zu erstellen. () Enthält immer noch die vollständige Anforderungskörper.
Beobachtetes Verhalten [/b]
Wenn eine Komponente den Körper frühzeitig liest, nachfolgende Aufrufe, um GetInputStream () einen leeren Stream zurückzugeben (leer ( read () == -1). > Wenn ja, wie können Sie den Eingabestream für spätere Lesen am besten zurücksetzen oder aktualisieren?