Warn message on displaying video content

[henning-gerhardt]

Describe the bug
On opening the meta data editor with a process which contains at least one video file a WARN message appears in the application log:

[http-nio-127.0.0.1-8080-exec-4] org.kitodo.production.handler.RangeStreamContentHandler - ClientAbortException generated by request GET http://<server of Kitodo.Production host>:443/kitodo/javax.faces.resource/dynamiccontent.properties.jsf

but the video will be played correctly. The amount of this message is raising if you use video files for thumbnail displaying in the structured and gallery view - but even here the thumbnails are show the first frame (or so).

To Reproduce
Steps to reproduce the behavior:

1. Open a process with at least one video file in the meta data editor
2. See at least one or more WARN messages in the application log.

Expected behavior
If there is a real issue then it should be solved. If this is only a message which can be ignored the log level should be lowered.

Release
at least on 3.7.2 but as the code did not change it should even in 3.8.x and main branch

Additional context
I digged in this a little bit deeper.

First I adjusted the log message in that way that I can see the full URI and got the real exception message

diff --git a/Kitodo/src/main/java/org/kitodo/production/handler/RangeStreamContentHandler.java b/Kitodo/src/main/java/org/kitodo/production/handler/RangeStreamContentHandler.java
index 79e6caac1..4121c771c 100644
--- a/Kitodo/src/main/java/org/kitodo/production/handler/RangeStreamContentHandler.java
+++ b/Kitodo/src/main/java/org/kitodo/production/handler/RangeStreamContentHandler.java
@@ -32,7 +32,6 @@ import javax.servlet.http.HttpServletResponse;
 
 import org.apache.logging.log4j.LogManager;
 import org.apache.logging.log4j.Logger;
-import org.apache.logging.log4j.message.ParameterizedMessage;
 import org.kitodo.production.beans.Range;
 import org.primefaces.application.resource.BaseDynamicContentHandler;
 import org.primefaces.model.StreamedContent;
@@ -91,8 +90,8 @@ public class RangeStreamContentHandler extends BaseDynamicContentHandler {
                 if (CLIENT_ABORT_EXCEPTION_CANONICAL_NAME.equals(e.getClass()
                         .getCanonicalName()) && externalContext.getRequest() instanceof HttpServletRequest) {
                     final HttpServletRequest request = (HttpServletRequest) externalContext.getRequest();
-                    logger.warn(new ParameterizedMessage("ClientAbortException generated by request {} {}",
-                            request.getMethod(), request.getRequestURL().toString()));
+                    logger.debug("ClientAbortException generated by request {} {}?{} Reason: {}", request.getMethod(),
+                        request.getRequestURL().toString(), request.getQueryString(), e.getMessage());
                 } else {
                     logger.error("Error in streaming dynamic resource.");
                     throw new IOException(e);

which looks than in that way:

org.kitodo.production.handler.RangeStreamContentHandler - ClientAbortException generated by request GET http://<server of Kitodo.Production host>:443/kitodo/javax.faces.resource/dynamiccontent.properties.jsf?ln=primefaces&v=8.0&v=8.0&pfdrid=27dab4b8fac082e318ef53f2c7f3936d&pfdrt=sc&mediaId=vid_dig_x_002818&process=815356&sessionId=b72625f0-6c39-4efa-b349-635648e0ac2b&type=video%2Fmp4&krsc=true&pfdrid_c=true Reason: java.io.IOException: Connection reset by peer 

After a some searching and discussing that message with @markusweigelt we agreed that this message can be ignored in case of the "Connection reset by peer" original exception message. The browser is getting the data but closing the connection before all data is transfered.

One more information: the full URI like shown in my extended log would lead to the real video file which can be played in the browser. In this time I was still logged in in the application and my used session was still valid. Maybe it is possible in that way to play video or any other content from other processes - which I did not tried. This could be already fixed in versions after 3.7.2 which I was using.