Oron Bendavid
Oron Bendavid

Reputation: 1533

cloud code function worked fine in Parse but not in back4app

After migrating my app from Parse.com to back4app platform, we started facing issues with cloud code functions.

I have a cloud code function which is calling the following url: http://www.pro.co.il/homeler/test.asp?c=6&a=51

And the error is: { [Error: Parse Error] bytesParsed: 373, code: 'HPE_UNEXPECTED_CONTENT_LENGTH' }

The cloud code function:

    Parse.Cloud.define("getFromPro", function (request, response) {
    return Parse.Cloud.httpRequest({
    url: 'http://www.pro.co.il/homeler/test.asp?c=' + request.params.classification + '&a=' + request.params.area,
    method: 'GET',
    headers: {
    'Content-Type': 'application/json;charset=utf-8'
    }
    }).then(function (httpResponse) {
        response.success(httpResponse);
    }, function (httpResponse) {
        response.error("not ok");
    });
});

Any idea if the issue is at back4app server, or I can fix it in my cloud code function?

Upvotes: 0

Views: 735

Answers (1)

Arthur Cinader
Arthur Cinader

Reputation: 1602

the issue is that the response you're getting from pro.co.il has two content-length headers:

curl -v http://www.pro.co.il/homeler/test.asp\?c\=6\&a\=51  
* Trying 195.190.23.112...
* Connected to www.pro.co.il (195.190.23.112) port 80 (#0)
> GET /homeler/test.asp?c=6&a=51 HTTP/1.1
> Host: www.pro.co.il
> User-Agent: curl/7.49.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Length: 1583
< Content-Type: text/html; Charset=UTF-8
< Expires: Sun, 31 Dec 1989 22:00:00 GMT
< Set-Cookie: ASPSESSIONIDCSCTSQSS=OBFNBKCBBPEDLKCIJNNLBJCD; path=/
< X-Powered-By: ASP.NET
< Accept-Ranges: bytes
< Date: Sat, 22 Oct 2016 15:08:28 GMT
< X-Varnish: 1532078109
< Age: 0
< Via: 1.1 varnish
< Connection: keep-alive
< Content-Length: 1583

When you moved from parse.com to parse-server, the library used for making Parse.Cloud.request changed to https://github.com/request/request which uses nodes http lib that is strict about headers for security reasons (though if the duplicate content-lengths match, as in this case, it would be reasonable to not error since it doesn't pose a security risk).

You can read about the issue here: https://github.com/nodejs/node/issues/6517

I looked at the request options to see if you can turn this off, but it looks like you can't.

Is it possible for you to get pro.co.il to fix their busted response?

Upvotes: 1

Related Questions