Proxy response gets truncated

[Zeetah]

When i create a proxy routes some of the proxyed files gets truncated and it happens only from time to time. We have loadbalancer with two nodes and its get even worse when we connect through it. It is working better when we connect straight to the node but sometimes not even then.

So if i make like 10 request with curl for example to path /static/js/filename.js which then proxies the request to localhost it breaks at least 5 time with answer:

url: (18) transfer closed with XXX bytes remaining to read .

The route looks like this:

{
            method: 'GET',
            path: '/static/{path*}',
            handler:{
                proxy: {
                    host: '127.0.0.1',
                    port: 8080,
                    protocol: 'http',
                    passThrough: true
                }
            }
}

If i connect straight to the nginx port then it allways comes correctly.

Is there any workaround for this?

We are using node 0.10.8 and Hapi 1.7.3 The static content are server with nginx/0.8.54

[geek]

Please upgrade to Hapi 1.8.1 as this issue is fixed. This is related to an open node bug around the response 'finish' event occasionally firing too early.

[Zeetah]

That seemed to fix the problem. We are testing it now and we will tell you if the problem occurs again.

And thanks to you @wpreul

[Zeetah]

Hi,

We manage to get the same problem when using https connection. We started using the 1.8.1 version but still in the https connection we get the broken result from time to time.

For example:

curl -O -k https://x.x.x.x/static/js/x.js
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
34 46048 34 15720 0 0 451k 0 --:--:-- --:--:-- --:--:-- 14.9M

curl: (18) transfer closed with 30328 bytes remaining to read

curl -O -k https://x.x.x.x/static/js/x.js
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 46048 100 46048 0 0 964k 0 --:--:-- --:--:-- --:--:-- 43.9M

Is there any way to get around this?

[Zeetah]

I think now that response fires finish event too early with https.

I tried with one hack and get it to work but it is not a real solution for the problem. In stream.js i modified the end functions callback to this:

setTimeout(function() {
callback();
},10);

[geek]

Fixed via a70ece1 I also added a test for https streaming. Please update to 1.8.2 to fix this issue.

Here is the related node issue: nodejs/node-v0.x-archive#5712

[Zeetah]

Could there be a still issue with this? We are experiencing problems with https and phones.. For example with Galaxy S3 Android stock browser and IPhone 4 Safari. Everything works fine on desktop browsers in http and https but at least with these two phones and their browsers we have the same problem as earlier.

[geek]

Are you still experiencing the issue after upgrading to 1.8.2?

[Zeetah]

Yes :(

The update fixed almost everything but the problem occurs in the mobile phones still.

[geek]

Related: nodejs/node-v0.x-archive@91698f7 and should land in 0.10.13

[geek]

0.10.13 is now released. Please try upgrading as the related tls bug may impact this issue: https://github.com/joyent/node/blob/v0.10.13-release/ChangeLog

[hueniverse]

@toniah Can you confirm the issue is fixed with node 0.10.13?

[leore]

Hey Eran,

We are getting this same issue and we are on V0.11.12-pre and hapi v2.6. Any idea what else could be causing this problem?

[pon]

@bavidar @hueniverse - this curl command demonstrates the issue we are receiving.
curl command:

 curl -O -k https://api.lob.com/v1/addresses?count=100 -u test_0dc8d51e0acffcb1880e0f19c79b2f5b0cc:

Response:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 94 56541   94 53248    0     0   259k      0 --:--:-- --:--:-- --:--:--  261k
curl: (18) transfer closed with 3293 bytes remaining to read

[hueniverse]

Can you test it also with node 0.10.26? And with http?

Also, since this issue was part of a release, please open a new issue describing the problem (you can just reference this one).