Atom feed shows bad web link

[TmCTux]

with mediagoblin 0.10, atom feed shows a base_url of 127.0.0.1:6543, which correspond to the main paste server.
Server has a standard installation with main paste and nginx front, with advised configuration.
Previous 0.9 installation was similar and atom feed showed the public web dns (without port as it is served on 80).

surely missing a configuration there or maybe a tweak to add to nginx conf?

thanks

[Ben Sturmfels]

If you "view source" on your MediaGoblin home page, can you give us the snippet of HTML that links to your Atom feed please? Something like:

<link rel="alternate" type="application/atom+xml" href="/atom/">

[TmCTux]

well, it is exactly that

<link rel="alternate" type="application/atom+xml" href="/atom/">

[Ben Sturmfels]

Replying to TmCTux:

well, it is exactly that

<link rel="alternate" type="application/atom+xml" href="/atom/">

Sorry that this reply is so long overdue! Looking at the code, the URLs of the atom feed are based on the URL of the HTTP request made. I presume you're seeing 127.0.0.1:6543 in the URLs because that's the host header being sent to the application.

I'd suggest taking a look at our deployment guide as I'm not aware of any issues with sites deployed with this approach (I'm not seeing this issue on my sites).

Let us know if you find out any more about this issue.

[TmCTux]

I've followed the deployment guide and reviewed my settings, I wasn't able to fix it yet.
I'm accessing mediagoblin from the internet through haproxy, maybe I can look there but this 127.0.0.1 doesn't make sense (worse case scenario could be an internal ip but not this loopback adress).
Does it really make sense to build the atom feed URL base on the http request and not base on the actual mediagoblin site base url?

Replying to Ben Sturmfels:

Replying to TmCTux:

well, it is exactly that

<link rel="alternate" type="application/atom+xml" href="/atom/">

Sorry that this reply is so long overdue! Looking at the code, the URLs of the atom feed are based on the URL of the HTTP request made. I presume you're seeing 127.0.0.1:6543 in the URLs because that's the host header being sent to the application.

I'd suggest taking a look at our deployment guide as I'm not aware of any issues with sites deployed with this approach (I'm not seeing this issue on my sites).

Let us know if you find out any more about this issue.

[TmCTux]

proposal to reopen - I feel the code works as intended but it may not fit any deployments use cases.

[Ben Sturmfels]

Hi TmCTux,

Would it be possible for me to take a look at your site directly? Pop me an email at ben at sturm.com.au or drop into the IRC channel at #mediagoblin on the libera.chat network.

Regards,
Ben

[Ben Sturmfels]

I'm sent TmCTux and email directly because I suspect that the issues tracker email notifications may not be being delivered to everyone due to an incorrect PTR record I just fixed.

[TmCTux]

Hello Ben,

indeed notifications have never been delivered till now (but it was also pushed to my spam folder so if it worked at some point, it may have been missed as well :))
I've sent you a mail a month ago but it hasn't be delivered.... I'm just seeing I've missed the last extension in your e-mail address... that may explain it :D
I'll try to disable haproxy temporarly and put a nginx in front to make the test you propose. Also, I can send you privately the web address of my instance if you need to check directly but I'm afraid a direct access to the server won't be feasible.

thanks again for your help!

[TmCTux]

Hello again,
so back at it :)
in fact, nginx was already there, as I said I've fully followed the deployment guide to be sure I wasn't missing something, my haproxy is again in front of nginx.
So if I curl directly mediagoblin served by nginx (so haproxy is out for this test), I'm seeing the same issue, rss link in the atom are in the form of ​http://127.0.0.1:6543.
As initially guessed, I was missing a basic nginx configuration, which is:

proxy_set_header Host $host;

to put into the proxy_pass settings

so no bug here, maybe an improvement for the documentation?

thanks again Ben for your kind support.

PS: I've saw this week-end that 0.12 was out (great!) and that it was replacing the rss/atom code, so I gave it a go just in case it impacted my error. well it didn't, but at least now I have the last upgrade, and this time you won't see a ticket from me for upgrade from 0.11 to 0.12, all went smouthly, perfect even!

thanks again for all
++

[Ben Sturmfels]

Hi TmCTux,

Thanks for helping solve this issue. I've updated the Nginx config documentation in 0.12.1 to include the Host header.

Regards,
Ben

[Ben Sturmfels]

Oops, forgot to link to it:
​https://docs.mediagoblin.org/en/stable/siteadmin/deploying.html#nginx-as-a-reverse-proxy

[Ben Sturmfels]

And sorry about the wonky subject - seems to be an issue since our Trac 1.4.3 upgrade. Now fixed!