New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all HTTP POSTs fail on ARM Processor #1151

Closed
FooBarWidget opened this Issue May 29, 2014 · 5 comments

Comments

Projects
None yet
2 participants
@FooBarWidget
Member

FooBarWidget commented May 29, 2014

From ageorgios on January 25, 2014 00:13:28

What steps will reproduce the problem? 1. Use a rails app on an ARM processor like raspberry pi
2. Make post request 3. What is the expected output? What do you see instead? expect posts to work like in x86,instead:
[Client 20] Disconnecting with error: invalid SCGI header What version of Phusion Passenger are you using? Which version of Rails? On what operating system? ruby 2.1.0, nginx 1.4.4 with passenger 4.0.35 on Raspbian on raspberry pi Please provide any additional information below.

Original issue: http://code.google.com/p/phusion-passenger/issues/detail?id=1052

@FooBarWidget

This comment has been minimized.

Show comment
Hide comment
@FooBarWidget

FooBarWidget May 29, 2014

Member

From andreas.stahlhofen on February 11, 2014 01:31:48

I also receives the same error on a raspberry pi. This problem was already discussed on Stackoverflow, but without a good solution. http://stackoverflow.com/questions/16443705/redmine-2-3-ruby-2-0-0-nginx-1-4-1-with-passenger-4-0-2-all-http-posts-fail Seems as if it would work with an older version of passenger (=3.0.19).

Member

FooBarWidget commented May 29, 2014

From andreas.stahlhofen on February 11, 2014 01:31:48

I also receives the same error on a raspberry pi. This problem was already discussed on Stackoverflow, but without a good solution. http://stackoverflow.com/questions/16443705/redmine-2-3-ruby-2-0-0-nginx-1-4-1-with-passenger-4-0-2-all-http-posts-fail Seems as if it would work with an older version of passenger (=3.0.19).

@FooBarWidget

This comment has been minimized.

Show comment
Hide comment
@FooBarWidget

FooBarWidget May 29, 2014

Member

From vdaubry on April 02, 2014 14:18:34

same problem here

Member

FooBarWidget commented May 29, 2014

From vdaubry on April 02, 2014 14:18:34

same problem here

@FooBarWidget

This comment has been minimized.

Show comment
Hide comment
@FooBarWidget

FooBarWidget May 29, 2014

Member

Maybe this is a bug in the SCGI parser, or maybe the SCGI generator. Unfortunately without access to ARM hardware I cannot test this.

Member

FooBarWidget commented May 29, 2014

Maybe this is a bug in the SCGI parser, or maybe the SCGI generator. Unfortunately without access to ARM hardware I cannot test this.

@nocelic

This comment has been minimized.

Show comment
Hide comment
@nocelic

nocelic Jul 13, 2014

Just ran into the same issue with Passenger 4.0.45 and both Nginx 1.4.6 and 1.6.0.
Debugged and found the cause in the following:

Passenger ContentHandler.c writes CONTENT_LENGTH SCGI header via

   b->last = ngx_copy(b->last, "CONTENT_LENGTH",
                       sizeof("CONTENT_LENGTH"));
   b->last = ngx_snprintf(b->last, 10, "%ui", r->headers_in.content_length_n);

However, "r->headers_in.content_length_n" is of "off_t" type for some reason, which is 64 bit long on recent ARM platforms, and also signed.
The proper conversion in this case is thus of "L", rather than "ui" type. On ARM this seems to make a difference.

With the last line above changed to

   b->last = ngx_snprintf(b->last, 10, "%L", r->headers_in.content_length_n);

POST requests started to work for me on ARM-HF.
But since off_t size might vary, this fix might break some other platforms, in particular 32-bit ones.
So as the ultimate solution I would propose:

   b->last = ngx_snprintf(b->last, 10, "%O", r->headers_in.content_length_n);

thereby letting the nginx code take care of the "off_t" sign and size.

nocelic commented Jul 13, 2014

Just ran into the same issue with Passenger 4.0.45 and both Nginx 1.4.6 and 1.6.0.
Debugged and found the cause in the following:

Passenger ContentHandler.c writes CONTENT_LENGTH SCGI header via

   b->last = ngx_copy(b->last, "CONTENT_LENGTH",
                       sizeof("CONTENT_LENGTH"));
   b->last = ngx_snprintf(b->last, 10, "%ui", r->headers_in.content_length_n);

However, "r->headers_in.content_length_n" is of "off_t" type for some reason, which is 64 bit long on recent ARM platforms, and also signed.
The proper conversion in this case is thus of "L", rather than "ui" type. On ARM this seems to make a difference.

With the last line above changed to

   b->last = ngx_snprintf(b->last, 10, "%L", r->headers_in.content_length_n);

POST requests started to work for me on ARM-HF.
But since off_t size might vary, this fix might break some other platforms, in particular 32-bit ones.
So as the ultimate solution I would propose:

   b->last = ngx_snprintf(b->last, 10, "%O", r->headers_in.content_length_n);

thereby letting the nginx code take care of the "off_t" sign and size.

@FooBarWidget

This comment has been minimized.

Show comment
Hide comment
@FooBarWidget

FooBarWidget Jul 13, 2014

Member

Great find. Thanks for contributing this fix!

Member

FooBarWidget commented Jul 13, 2014

Great find. Thanks for contributing this fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment