Bug 1127925 - HTTP Range Headers not being passed to app
Summary: HTTP Range Headers not being passed to app
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: Image
Version: 1.x
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Maciej Szulik
QA Contact: libra bugs
: 1203498 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-07 20:56 UTC by Trey
Modified: 2019-06-13 08:02 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-04-16 00:38:16 UTC

Attachments (Terms of Use)

Description Trey 2014-08-07 20:56:16 UTC
Description of problem:

In a scalable app the HTTP Range Headers aren't being passed to the app through haproxy

Version-Release number of selected component (if applicable):

How reproducible:

Every Time

Steps to Reproduce:
1.Create a scalable Node.JS App
2.In the app load express and in a route look for req.headers.range
3.Make a request to route from step 2 with a Range header present

Actual results:

Range Header isn't present

Expected results:

Range Header to be present

Additional info:

Comment 1 Jose A Andujar Clavell 2014-09-19 06:56:32 UTC
I think this bug must have a higher priority.

People are migrating from openshift to another solutions

A lot of Mobile companies need this solution (like ours), because downloading a big file from mobile could have problems, and having range header is the solution for resuming downloads.

Comment 3 Andy Grimm 2014-10-08 15:21:03 UTC
More detail on this:  it is not specific to scaled apps, and not related to haproxy whatsoever.  It is the Apache frontend on the node that is dropping the header.  We have intentionally disabled range headers at the present time.  See


However, the justification in that issue ( CVE-2011-3192 ) is not valid reasoning, as that security issue was fixed years ago, and the change I found that introduced the byteranges=no setting was two years ago, well after that CVE was resolved.  I talked to Dan McPherson, and he seemed to recall that there was a different problem with passing range headers, so we need to test a new configuration to ensure that enabling them works as we expect.

Comment 5 david.munger 2015-01-20 04:41:05 UTC
Is there any movement on this? I'm having this same problem with a Ruby cartridge on which I'm running Sinatra/Padrino. The whole point of my site is to play a large audio mix (mp3 file) inside of a browser-based player. The mix always drops out at the same point. I forced a 206 status on the response, and then I get an explicit 'Accept-Ranges:none' header back on the response.

I'm afraid this is a deal-breaker for me too. And it appears Openshift doesn't consider it a high priority. I also notice the status is still "New," which looks like this bug hasn't even been acknowledged, but ignored so far? That's unfortunate, because I've been very happy with Openshift so far and was considering upgrading to the Silver plan, but since this issue hasn't been resolved since it was reported in August of last year, I can only assume it isn't important to Openshift, and that they are okay with losing customers that need it. I don't mean that in a snarky way, just deductive reasoning.

Comment 6 Alessandro Mariotti 2015-02-13 11:45:42 UTC
I am looking forward for a solution to this issue.

Comment 9 Mario 2015-04-01 22:29:07 UTC
Dear all,
I am facing the same problem by using a Wildfly 8.2 container.
I have a web application deployed on it and one of the services exposed is related to a stream video api. I need to set the Accept-Range header, how can I solve the problems?

Please help.

Comment 10 Andy Grimm 2015-04-07 16:56:37 UTC
There is a configuration change being deployed this afternoon to fix this.  It should reach all nodes later today.

Comment 11 Paul Morie 2015-04-07 17:42:25 UTC
*** Bug 1203498 has been marked as a duplicate of this bug. ***

Comment 12 openshift-github-bot 2015-06-11 20:21:27 UTC
Commit pushed to master at https://github.com/openshift/li

Bug 1127925 - Node proxy should accept HTTP Range headers

Note You need to log in before you can comment on or make changes to this bug.