[Mojolicious] Nginx reverse proxy to Hypnotoad

Discussion:

Jan Eskilsson

2018-11-04 17:55:25 UTC

Hi All

We have a strange problem that i wonder if someone else also have
encountered. We have started to do some tests on the live servers and found
that everything works perfect with one exception. We get a lot of .jpg
files and after we set up https they are not readable on disk anymore. If
we downgrade to http it all works again so i wonder if someone else has
seen and solved this problem ?

I understand this is not really a Hypnotoad problem but probably some
setting in Nginx, but I can't figure out what it might be that is wrong,
Nginx conf is below and I have messed with every setting soon i think
except the correct one obviously :-)

Both servers are Centos 7

server {
listen 443 ssl http2 ;
server_name matorit.laga.se;
root /media/sf_root/matorit/html;
ssl on;
ssl_certificate "/etc/pki/nginx/laga_se.pem";
ssl_certificate_key "/etc/pki/nginx/private/laga_se.key";
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;

location /api {
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
proxy_buffering on;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 1000m;
client_max_body_size 1000m;

proxy_pass http://matorit;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Nginx-Proxy true;
proxy_set_header X-Forwarded-Ssl off;

Thank you in advance

Best Regards
Jan
--
Titles mean nothing. The one with a servant's heart is the leader.

Please consider the environment before you print this email.

All incoming and outgoing emails and any attachments are subjected to a
virus scanner and are believed to be free of any virus, or any other defect
which might affect any computer or IT system into which they are received
and opened. Therefore, it is the responsibility of the recipient to ensure
that they are virus free and no responsibility is accepted by Jan Eskilsson
for any loss or damage arising in any way from receipt or use thereof.

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Jason Cooper

2018-11-05 10:21:48 UTC

Permalink

Hi Jan,
I'm having a bit of trouble understanding the problem you've described.
Is uploading of files that you've got a problem or downloading them?

If the problem is with uploading then does it create the file but you
don't have permissions to read it; does it create the file but it's empty
or does it not create the file at all?

If the problem is with downloading and it's happening on a webpage that
was http but is now https, then it could be your browser not liking the
some absolute URLs in your page - check your browser's console for mixed
content errors.

Regards,
Jason.

Post by Jan Eskilsson
Hi All
We have a strange problem that i wonder if someone else also have
encountered. We have started to do some tests on the live servers and found
that everything works perfect with one exception. We get a lot of .jpg
files and after we set up https they are not readable on disk anymore. If
we downgrade to http it all works again so i wonder if someone else has
seen and solved this problem ?
I understand this is not really a Hypnotoad problem but probably some
setting in Nginx, but I can't figure out what it might be that is wrong,
Nginx conf is below and I have messed with every setting soon i think
except the correct one obviously :-)
Both servers are Centos 7
server {
listen 443 ssl http2 ;
server_name matorit.laga.se;
root /media/sf_root/matorit/html;
ssl on;
ssl_certificate "/etc/pki/nginx/laga_se.pem";
ssl_certificate_key "/etc/pki/nginx/private/laga_se.key";
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location /api {
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
proxy_buffering on;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 1000m;
client_max_body_size 1000m;
proxy_pass http://matorit;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Nginx-Proxy true;
proxy_set_header X-Forwarded-Ssl off;
Thank you in advance
Best Regards
Jan
--
Titles mean nothing. The one with a servant's heart is the leader.
Please consider the environment before you print this email.
All incoming and outgoing emails and any attachments are subjected to a
virus scanner and are believed to be free of any virus, or any other defect
which might affect any computer or IT system into which they are received
and opened. Therefore, it is the responsibility of the recipient to ensure
that they are virus free and no responsibility is accepted by Jan Eskilsson
for any loss or damage arising in any way from receipt or use thereof.

Jan Eskilsson

2018-11-05 10:55:22 UTC

Permalink

Hi Jason

Thank ypou for your response !

Its with the uploading, I have permission to read the file as soon as its
uploaded and its created with the correct size but the file is corrupt i.e.
its not a .jpg. If i understand correctly this setting in the nginx.conf
proxy_pass http://matorit; should make sure that its only http that's
redirected to the server with hypnotoad running.

If i change to http, listen 80; in the nginx.conf the files are created
correctly i.e. they are readable .jpg's

Hypnotoad is running with proxy => 1.

Best Regards
Jan

Post by Jason Cooper
Hi Jan,
I'm having a bit of trouble understanding the problem you've described.
Is uploading of files that you've got a problem or downloading them?
If the problem is with uploading then does it create the file but you
don't have permissions to read it; does it create the file but it's empty
or does it not create the file at all?
If the problem is with downloading and it's happening on a webpage that
was http but is now https, then it could be your browser not liking the
some absolute URLs in your page - check your browser's console for mixed
content errors.
Regards,
Jason.

--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

--
Titles mean nothing. The one with a servant's heart is the leader.

Please consider the environment before you print this email.

All incoming and outgoing emails and any attachments are subjected to a
virus scanner and are believed to be free of any virus, or any other defect
which might affect any computer or IT system into which they are received
and opened. Therefore, it is the responsibility of the recipient to ensure
that they are virus free and no responsibility is accepted by Jan Eskilsson
for any loss or damage arising in any way from receipt or use thereof.

Jason Cooper

2018-11-05 14:09:02 UTC

Permalink

Hi Jan,
I just put together the following simple Mojolicious script to try and
recreate your issue, but it seems to work fine with JPEGs when I try it
behind an NGINX proxy terminiating SSL.

#!/usr/bin/env perl

use Mojolicious::Lite;

# Upload form in DATA section
get '/api/form' => 'form';

# Multipart upload handler
post '/api/upload' => sub {
my $c = shift;

# Check file size
return $c->render(text => 'File is too big.', status => 200)
if $c->req->is_limit_exceeded;

# Process uploaded file
return $c->redirect_to('form') unless my $example =
$c->param('example');
my $size = $example->size;
my $name = $example->filename;

$example->move_to("/tmp/$name");

$c->render(text => "Thanks for uploading $size byte file $name.");
};

app->config(hypnotoad => {listen => ['http://*:3000']});

app->start;
__DATA__

@@ form.html.ep
<!DOCTYPE html>
<html>
<head><title>Upload</title></head>
<body>
%= form_for apiupload => (enctype => 'multipart/form-data') => begin
%= file_field 'example'
%= submit_button 'Upload'
% end
</body>
</html>

If you have a safe environment to test then it might be worth creating a
simple script like the one above to test with (feel free to use the one
above, just make sure that it doesn't overwrite anything you require in
your `/tmp` directory).

Do you get any errors in your logs that might indicate what's going on?

Regards,
Jason.

Post by Jan Eskilsson
Hi Jason
Thank ypou for your response !
Its with the uploading, I have permission to read the file as soon as its
uploaded and its created with the correct size but the file is corrupt i.e.
its not a .jpg. If i understand correctly this setting in the nginx.conf
proxy_pass http://matorit; should make sure that its only http that's
redirected to the server with hypnotoad running.
If i change to http, listen 80; in the nginx.conf the files are created
correctly i.e. they are readable .jpg's
Hypnotoad is running with proxy => 1.
Best Regards
Jan

Post by Jason Cooper
Hi Jan,
I'm having a bit of trouble understanding the problem you've
described. Is uploading of files that you've got a problem or downloading
them?
If the problem is with uploading then does it create the file but you
don't have permissions to read it; does it create the file but it's empty
or does it not create the file at all?
If the problem is with downloading and it's happening on a webpage that
was http but is now https, then it could be your browser not liking the
some absolute URLs in your page - check your browser's console for mixed
content errors.
Regards,
Jason.

--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

--
Titles mean nothing. The one with a servant's heart is the leader.
Please consider the environment before you print this email.
All incoming and outgoing emails and any attachments are subjected to a
virus scanner and are believed to be free of any virus, or any other defect
which might affect any computer or IT system into which they are received
and opened. Therefore, it is the responsibility of the recipient to ensure
that they are virus free and no responsibility is accepted by Jan Eskilsson
for any loss or damage arising in any way from receipt or use thereof.

Jan Eskilsson

2018-11-05 17:21:33 UTC

Permalink

Hi Jason

Thank you very much, I tested your script using your upload page and it
worked !!!

So I tested my upload script, which uses LWP::UserAgent and
HTTP::Request::Common, against your api and I got the same problem with
corrupt files as I had using my api. This pointed me in the correct
direction, i messed around a bit in the upload script and i found
that $HTTP::Request::Common::DYNAMIC_FILE_UPLOAD = 1; changed
to $HTTP::Request::Common::DYNAMIC_FILE_UPLOAD = 0; solved the problem. I
don't 100% understand why but it wont be a problem since the jpg files are
all small.

Thank you again for pointing me in the correct direction and for giving me
a bit of an eyeopener for Mojolicious::Lite.

Best Regards
Jan

Post by Jason Cooper
Hi Jan,
I just put together the following simple Mojolicious script to try and
recreate your issue, but it seems to work fine with JPEGs when I try it
behind an NGINX proxy terminiating SSL.
#!/usr/bin/env perl
use Mojolicious::Lite;
# Upload form in DATA section
get '/api/form' => 'form';
# Multipart upload handler
post '/api/upload' => sub {
my $c = shift;
# Check file size
return $c->render(text => 'File is too big.', status => 200)
if $c->req->is_limit_exceeded;
# Process uploaded file
return $c->redirect_to('form') unless my $example =
$c->param('example');
my $size = $example->size;
my $name = $example->filename;
$example->move_to("/tmp/$name");
$c->render(text => "Thanks for uploading $size byte file $name.");
};
app->config(hypnotoad => {listen => ['http://*:3000']});
app->start;
__DATA__
@@ form.html.ep
<!DOCTYPE html>
<html>
<head><title>Upload</title></head>
<body>
%= form_for apiupload => (enctype => 'multipart/form-data') => begin
%= file_field 'example'
%= submit_button 'Upload'
% end
</body>
</html>
If you have a safe environment to test then it might be worth creating a
simple script like the one above to test with (feel free to use the one
above, just make sure that it doesn't overwrite anything you require in
your `/tmp` directory).
Do you get any errors in your logs that might indicate what's going on?
Regards,
Jason.

Post by Jan Eskilsson
Hi Jason
Thank ypou for your response !
Its with the uploading, I have permission to read the file as soon as its
uploaded and its created with the correct size but the file is corrupt i.e.
its not a .jpg. If i understand correctly this setting in the nginx.conf
proxy_pass http://matorit; should make sure that its only http that's
redirected to the server with hypnotoad running.
If i change to http, listen 80; in the nginx.conf the files are
created correctly i.e. they are readable .jpg's
Hypnotoad is running with proxy => 1.
Best Regards
Jan

Post by Jason Cooper
Hi Jan,
I'm having a bit of trouble understanding the problem you've
described. Is uploading of files that you've got a problem or downloading
them?
If the problem is with uploading then does it create the file but you
don't have permissions to read it; does it create the file but it's empty
or does it not create the file at all?
If the problem is with downloading and it's happening on a webpage
that was http but is now https, then it could be your browser not liking
the some absolute URLs in your page - check your browser's console for
mixed content errors.
Regards,
Jason.

--
You received this message because you are subscribed to the Google
Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

--
Titles mean nothing. The one with a servant's heart is the leader.
Please consider the environment before you print this email.
All incoming and outgoing emails and any attachments are subjected to a
virus scanner and are believed to be free of any virus, or any other defect
which might affect any computer or IT system into which they are received
and opened. Therefore, it is the responsibility of the recipient to ensure
that they are virus free and no responsibility is accepted by Jan Eskilsson
for any loss or damage arising in any way from receipt or use thereof.