403 Passthrough Issue Using NGINX and EC2

[Christopher King]

As discussed in another thread, my app creates Urbit ships running on NGINX on EC2 instances. It seems certain features of Landscape are taking a long time to load, and multiple refreshes are sometimes needed. There are 403 errors and the EventSource channel sometimes cannot connect. These issues have mostly been identified by John Franklin.

Matilde Park thinks it is an issue with configuring the passthrough in my setup. How do I do this correctly in an NGINX context? Or is it not an NGINX issue at all?

[Brendan Hay]

What do the nginx logs say for the 403? Is the 403 coming from eyre? Also if the EventSource cannot connect to the upstream ship/eyre, then nginx should return a 50x - is that the case?

If possible could you share an example nginx configuration, so I or someone else could eyeball it - although I’m just logging off so there’ll be some latency.

[Christopher King]

The core issue seems to be indicated by the following logs in the console when in Landscape:

XML Parsing Error: no root element found

Location: http://100.26.155.46/~/channel/1600827631997-97c68c
Line Number 1, Column 1: 1600827631997-97c68c:1:1

Copying John Franklin who identified this issue.

[Mark]

fwiw I get those "XML Parsing Error" prints a lot on my ship too, but don't experience any other issues. I don't think it's related to your issue here.

Seconding a request for your nginx config, it could be relevant.

—
~palfun-foslup
https://urbit.org

[Christopher King]

Mark: see nginx config here.

[Mark]

As per this stack overflow answer, which has made the rounds before:
https://stackoverflow.com/a/13673298/1334324

I'd add the following to your location block:

proxy_set_header Connection '';
proxy_http_version 1.1;
chunked_transfer_encoding off;
proxy_buffering off;
proxy_cache off;

This should resolve any issues around connecting to Urbit's SSE endpoints.

I personally also recommend adding this line:

proxy_set_header Forwarded for=$remote_addr;

because eyre respects the Forwarded header now, letting applications dispatch off of an actual IP address, rather than 127.0.0.1.
(This doesn't really matter for the apps that currently ship with arvo by default, but it's future-proof and seems like good behavior for proxy servers in general.)

—
~palfun-foslup
https://urbit.org

[Christopher King]

Both in nginx.conf, right? So nothing in ssl.conf needs to change?

[Mark]

Oh, right, these are separate configs for the http and https servers. I think you want to add this to the location / { ... } block in both files, then.

—
~palfun-foslup
https://urbit.org

[Christopher King]

That seems to have done it. Thanks Mark.