Bug 1203498

Summary: HTTP Partial Content Unsupported
Product: OpenShift Online Reporter: Derek Menteer <leechy9>
Component: ContainersAssignee: Dan Mace <dmace>
Status: CLOSED DUPLICATE QA Contact: libra bugs <libra-bugs>
Severity: high Docs Contact:
Priority: medium    
Version: 2.xCC: agrimm, jokerman, leechy9, libra-bugs, m.fiorentino, mmccomas, pmorie
Target Milestone: ---   
Target Release: 2.x   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-07 17:42:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
206 Partial implementation none

Description Derek Menteer 2015-03-19 02:07:48 UTC 
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.
Comment 1 Derek Menteer 2015-03-19 02:16:29 UTC 
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>
Comment 2 Dan Mace 2015-03-19 18:56:35 UTC 
Created attachment 1004135 [details]
206 Partial implementation

A simple WSGI application demonstrating 206 partial functionality.
Comment 3 Dan Mace 2015-03-19 19:00:05 UTC 
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.
Comment 4 Derek Menteer 2015-03-19 21:13:44 UTC 
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.
Comment 5 Mario 2015-04-04 11:18:16 UTC 
I am facing the sam problem. Is there any update?
Comment 6 Mario 2015-04-04 11:19:24 UTC 
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?
Comment 8 Paul Morie 2015-04-07 17:42:25 UTC 
Closing this as it duplicates 1127925

*** This bug has been marked as a duplicate of bug 1127925 ***