Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Constant error 416 for a byte-range request with content type application/octet-stream [SPR-15041] #19607

Closed
spring-issuemaster opened this issue Dec 22, 2016 · 4 comments

Comments

@spring-issuemaster
Copy link
Collaborator

commented Dec 22, 2016

Sebastian Slepowronski opened SPR-15041 and commented

Hi guys,

we're experiencing issues with serving the static resources of "application/octet-stream" with the byte-range requests.

After adding a resource location by extending a

WebMvcConfigurerAdapter#addResourceHandlers

and performing the byte-range request (it can be either "Range=bytes:0-" or "Range=bytes:1-3"), it is always concluded with error 416 "Requested range not satisfiable".

I have debugged Spring a bit and the exception causing our error 416 is "'Content-Type' cannot contain wildcard type '*'" raised in the

HttpHeaders#setContentType

The root cause of this exception is a null media type.
We have got a media type set up:

spring.mvc.media-types.dat: application/octet-stream

At the beginning, it works correctly and the desired content type is used but at the end of the getting media type flow we are meeting such a condition in the PathExtensionContentNegotiationStrategy#getMediaTypeForResource:

if(MediaType.APPLICATION_OCTET_STREAM.equals(mediaType)) {
    mediaType = null;
}

what of course causes a null mediaType and finally an error 416 in the ResourceHttpRequestHandler#handleRequest.

I suspect that there was a deeper reasoning with discarding the application/octet-stream so explicitly. Could you please share what is the reason of such a behaviour?

We would like to achieve a goal of serving static application/octet-stream resources with byte-range support. Could you please tell whether a condition above is correct or what would be another way to achieve this goal?

FYI: Our working workaround for this issue is declaring an image content type:

spring.mvc.media-types.dat: image/jpeg

Byte range requests are working with such an approach and correctly return the 206 Partial Content.

Great thanks for your help and time.

Best regards


Affects: 4.3.3

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 23, 2016

Brian Clozel commented

Hi SebastianSlepowronski,

What happens if you remove the Spring Boot option spring.mvc.media-types.dat: application/octet-stream altogether and let the resource handling infrastructure choose application/octet-stream by itself (which is the default)?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 27, 2016

Sebastian Slepowronski commented

Hi Brian Clozel,

after removing a

spring.mvc.media-types.dat: application/octet-stream

the final result is the same (error 416). However, there's an interesting situation happening in the PathExtensionContentNegotiationStrategy#getMediaTypeForResource. mediaType is correctly set to the application/octet-stream by:

if(mediaType == null && JAF_PRESENT) {
    mediaType = PathExtensionContentNegotiationStrategy.ActivationMediaTypeFactory.getMediaType(filename);
}

but discarded immediately after that, in the following condition (the same place as before):

if(MediaType.APPLICATION_OCTET_STREAM.equals(mediaType)) {
    mediaType = null;
}

To sum up, a mediaType is initially set to application/octet-stream and discarded in the same place for both cases.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 3, 2017

Brian Clozel commented

This is now fixed and should be available soon in the next 4.3.6.BUILD-SNAPSHOT if you'd like to test this.

The ResourceRegionHttpMessageConverter wasn't selecting the proper default content-type, unlike its Resource counterpart. Thanks for this report!

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 3, 2017

Sebastian Slepowronski commented

Great, thanks!
Sure, I will check it out :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.