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:
I think this bug must have a higher priority. People are migrating from openshift to another solutions http://stackoverflow.com/questions/25191555/http-range-header-openshift-scalable-app 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.
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 https://bugzilla.redhat.com/show_bug.cgi?id=1109468 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.
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.
I am looking forward for a solution to this issue.
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. Mario
There is a configuration change being deployed this afternoon to fix this. It should reach all nodes later today.
*** Bug 1203498 has been marked as a duplicate of this bug. ***
Commit pushed to master at https://github.com/openshift/li https://github.com/openshift/li/commit/d673ce9bfa206e0b15fc0054c4137b7221983d4b Bug 1127925 - Node proxy should accept HTTP Range headers