Class SendfileProviderTest

java.lang.Object
ubic.gemma.rest.providers.SendfileProviderTest
public class SendfileProviderTest extends Object
Pins the sendfile-vs-content-encoding interaction in SendfileProvider.

Tomcat sendfile writes the file at the connector level and never touches the entity stream, so if a WriterInterceptor has wrapped that stream for compression, taking the sendfile path emits unencoded bytes under an encoding header — a response no conforming client can read. The provider has to notice and stand down.

  • Constructor Details

    • SendfileProviderTest

      public SendfileProviderTest()

  • Method Details

    • setUp

      @BeforeEach public void setUp() throws IOException
      Throws:
      IOException

    • plainStreamTakesTheSendfilePath

      @Test public void plainStreamTakesTheSendfilePath() throws IOException
      Throws:
      IOException

    • wrappedStreamFallsBackToStreamingThroughTheEncoder

      @Test public void wrappedStreamFallsBackToStreamingThroughTheEncoder() throws IOException
      The guard. An encoder wrapped the stream, so sendfile must be skipped and the file written through the wrapper instead — otherwise the client gets plain text labelled Content-Encoding: gzip.
      Throws:
      IOException

    • encodingHeaderWithoutAWrappedStreamStillUsesSendfile

      @Test public void encodingHeaderWithoutAWrappedStreamStillUsesSendfile() throws IOException
      A Content-Encoding header alone must NOT disable sendfile: that is exactly the situation of the endpoints declaring @GZIP(alreadyCompressed = true), whose header is appended after the encoder has already declined to wrap the stream. Treating the header as the signal would quietly drop every large file download off the zero-copy path.
      Throws:
      IOException