Nachdem der Filter fehlschlägt, geben alle weiteren Anfragen an diesen Endpunkt „Verbindung abgelehnt“ zurück. ⇐ Java

[Anonymous]

Spring Boot 3.4.1, Java 21
Ich habe einen Filter geschrieben, der nichts weiter tut, als die Anfragegröße anhand eines konfigurierbaren Maximums zu prüfen und 413 zurückzugeben, wenn die Anfrage zu groß ist .

Code: Select all

@Component
@Order(Ordered.HIGHEST_PRECEDENCE)
@Slf4j
public class RequestSizeFilter implements Filter {

@Value("${fam.max_request_size:10485760}")
private int maxContentBytes;

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException {
try {
if (request.getContentLength() > maxContentBytes) {
throw new RuntimeException();
} else {
chain.doFilter(request, response);
}
} catch (Exception e) {
log.error("Detected overlarge request of %s bytes. Rejecting.".formatted(request.getContentLength()));
HttpServletResponse httpResponse = (HttpServletResponse) response;
httpResponse.setStatus(HttpServletResponse.SC_REQUEST_ENTITY_TOO_LARGE);
httpResponse.getWriter().println("Request exceeds maximum size of %s bytes".formatted(maxContentBytes));
}

}
}

Wenn ich meine automatisierten Tests für den dadurch geschützten Endpunkt ausführe, erkennt der Filter die übergroße Anfrage korrekt und lehnt sie mit dem entsprechenden Status und der entsprechenden Fehlermeldung ab. Das Problem scheint darin zu bestehen, dass nach dieser Ablehnung jeder andere Test, der versucht, diesen Endpunkt zu erreichen, mit
fehlschlägt

Code: Select all

org.springframework.web.reactive.function.client.WebClientRequestException: Connection refused: localhost/[0:0:0:0:0:0:0:1]:8080
at app//org.springframework.web.reactive.function.client.ExchangeFunctions$DefaultExchangeFunction.lambda$wrapException$9(ExchangeFunctions.java:137)

Caused by:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: localhost/[0:0:0:0:0:0:0:1]:8080

Caused by:
java.net.ConnectException: Connection refused
at java.base/sun.nio.ch.Net.pollConnect(Native Method)
at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:682)
at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:973)
at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:336)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:339)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:1583)

Dabei handelt es sich um vollständige End-to-End-Integrationstests, sodass der Kontext, in dem die App ausgeführt wird, derselbe ist wie in der Produktion. Der Client, den wir verwenden, um diese Endpunkte zu erreichen, ist eine benutzerdefinierte Erweiterung der integrierten WebTestClient-Klasse von Spring, wobei nichts weiter als eine Basis-URL und ein Standardautorisierungsheader für alle Anfragen festgelegt werden.
Das Interessante Die Sache ist, dass alle meine anderen Tests erfolgreich sind, wenn ich den Test deaktiviere, der diesen Filter auslöst. Da die Testreihenfolge nicht garantiert ist, weiß ich außerdem, dass derselbe Test, der vor dem Test, der diesen Filter auslöst, bestanden wird, fehlschlägt, wenn er danach ausgeführt wird. Der Filter muss den Server in einem instabilen Zustand belassen, aber ich kann nicht feststellen, wie oder warum. Benötige ich einen Anruf, um den Dienst wieder in einen Zustand zu versetzen, in dem er wieder eingehende Verbindungen annehmen kann?