AbstractMessageConverterMethodProcessor doesn't respect already handled headers and result-codes [SPR-16921]

[spring-projects-issues]

Alexander Schuetz opened SPR-16921 and commented

We support ranged requests at specific entrypoints in our REST-API (especially for embedding videos and other large documents).

Since we don't work on files and the data is potentially large we cannot use File-resources and don't want to use byte[]. Instead we are using InputStreamResource which only contains the requested range of data as stream.

The controller method sets the status code 206 and also sets the following headers:

• ETag
• Content-Disposition
• Accept-Ranges
• Content-Range

In version 4.3.17.RELEASE everything works fine and i.e. videos are displayed correctly in browsers Chrome, Firefox and InternetExporer.

Upgrading to version 5.0.2 breaks this functionality, since AbstractMessageConverterMethodProcessor tries to handle the ranged-request itself and doesn't recognize that it has already been handled. Thus it calls InputStreamResource.getContentLength() and tries to read the InputStream afterwards which results in an Exception, since the stream can only be read once. => status code 500 is returned.

 

We needed to return to spring version 4 because of this behaviour.

---

Affects: 5.0.2

Issue Links:

• IllegalStateException: InputStream has already been read when returning ResponseEntity<InputStreamResource> [SPR-16754] #21295 IllegalStateException: InputStream has already been read when returning ResponseEntity

Referenced from: commits 818e4b0

[spring-projects-issues]

Juergen Hoeller commented

This looks like a duplicate of #21295: Could you try whether an upgrade to Spring Framework 5.0.6 solves the problem for you please? Any specific reason why you tried 5.0.2?

[spring-projects-issues]

Alexander Schuetz commented

We were using spring-boot-starter web 2.0.0.RELEASE:

<dependencyManagement>
    <dependencies>
        <dependency>
            <!-- Import dependency management from Spring Boot -->
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <!-- This version will break ranged-requests made by html5 video-tags -->
            <!--<version>2.0.0.RELEASE</version>-->
            <version>1.5.13.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

I will try out version 5.0.6 and report back It sounds promisable.

[spring-projects-issues]

Juergen Hoeller commented

Spring Boot 2.0.2 brings Spring Framework 5.0.6 with it, so ideally you'd just bump up your Boot version.

[spring-projects-issues]

Alexander Schuetz commented

I can confirm, that with Spring Framework 5.0.6 (Spring Boot 2.0.2) for InputStreamResource no error status 500 gets delivered.

Nevertheless I think the Framwork shouldn't try to handle ranged requests if the application already handled it and signals it:

1. with status code 206 and corresponding headers "Content-Range", "Accept-Ranges": The Resource already only contains the requested data and every attempt to reevaluate whether the range is satisfiable or the correct value for "Content-Range"-header (especially total length) is going to yield wrong results!
2. with status-code 304 since it is not modified
3. with status code 416 since it already evaluated the range is unsatisfiable

Since this is the original intention of my ticket, I don't consider it as duplicate of SPR 16754.

[spring-projects-issues]

Juergen Hoeller commented

Brian Clozel, assigning this one to you for further consideration (related to #21295).

[spring-projects-issues]

Brian Clozel commented

I've slightly refined the conditions to trigger the Content-Range support from Controllers. This will let Controllers handle that themselves. We're now triggering that support only if the HTTP response is "200 OK", as other cases might show that content range has been handled already (206, 416) or don't really fit with the general use cases considered by the Framework.

Thanks for the report Alexander Schuetz!