Description of problem: HTTP partial content is not supported on Openshift WSGI applications using the provided Apache server. Any responses sent through to the application have the status code 206 stripped replaced with 200 and the `Accept-Ranges` header value set to `none`. How reproducible: very consistent / reliable Steps to Reproduce: 1. Create a WSGI application that sends partial content and appropriate headers 2. Attempt partial request of file in Chrome / Firefox, ensuring the `Range` header is sent. 3. Full file will be returned instead of partial content requested. The `Accept-Ranges` response headers will be changed from the values provided by the WSGI application. Actual results: HTTP Status Code: 200 OK Accept-Ranges: none Expected results: HTTP Status Code: 206 PARTIAL CONTENT Accept-Ranges: bytes Additional info: Protocol info available in section 10.2.7 at <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html> This functionality is necessary for serving large files (notably audio and video). Without it, Chrome will attempt to stream the content instead of fully downloading it; this eventually causes a timeout on the OpenShift's end, effectively rendering downloads on those forms of media useless.
Better / more direct links to appropriate topics. 206 Partial Content <http://tools.ietf.org/html/rfc2616#section-10.2.7> Byte Ranges <http://tools.ietf.org/html/rfc2616#section-14.35>
Created attachment 1004135 [details] 206 Partial implementation A simple WSGI application demonstrating 206 partial functionality.
I've attached a simple WSGI application which can be dropped into a new python-3 application on OpenShift. The application demonstrates the root problem: the Accept-Ranges header is being actively mutated by the node proxy due to an apache CVE: https://bugzilla.redhat.com/show_bug.cgi?id=1109468 Response codes are not mutated as implied by the initial bug report. Only the Accept-Ranges header is affected. I'm still working on sorting out what the plan is to upgrade apache and remove the Accept-Ranges header filter from the node proxies.
I can confirm that my original statement about the status code being changed is false. I had used a browser that automatically corrected the headers for me. After using curl for testing, it shows the 206 response.
I am facing the sam problem. Is there any update?
I have a web application deployed on openshift by using Wildfly 8.2 as container. This WebApplication exposes a service that is used to make video stream over http and in order to let him work in a proper way I need to set the Accept-Ranges=bytes in the HTTP response header of the packet. I've tried the following: 1. By code using the HttpServletResponse and setting the headers values, 2. By setting in the standalone.xml of the container the header value if the request prefix of the path ends with .mp4 The problem is that, in both ways, although I am correctly setting the header it seems that OPENSHIFT at the end override the value of the Accept-Range to none. Please help, what can I do?
Closing this as it duplicates 1127925 *** This bug has been marked as a duplicate of bug 1127925 ***