Redirect loop happens in $request_uri


#1

Hello there,

I have came across a situation, where the site is working, but the path to replies isn’t.
You may visit the main site here: https://discuss.stickyricelove.com
And any replies like this one here: 男友背住我同另一個女仔傾計 - LOVE:: 有關愛情的 - Sticky Rice Love 糖不甩

I have rebuilt many times over the last night, restarted and updated all things, yet still can’t figure out what’s the cause of this. Here is some configurations in use for references, hopefully someone can shed some lights on this problem:

nginx.conf

  server{
    listen 443 ssl http2;       # Deprecating IPv4
    listen [::]:443 ssl http2;
    server_name discuss.stickyricelove.com;

    location / {
        proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        proxy_redirect    off;
        proxy_set_header  X-Url-Scheme $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto "https";

    }
  }

containers/app.yml

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.socketed.template.yml"

The socket

[root@donut discourse]# ls -al /var/discourse/shared/standalone/nginx.http.sock
srwxrwxrwx 1 root root 0 Sep 19 08:45 /var/discourse/shared/standalone/nginx.http.sock

The access log for the example path above

172.20.209.164 - - [19/Sep/2017:09:22:04 +0800] "GET /t/%E7%94%B7%E5%8F%8B%E8%83%8C%E4%BD%8F%E6%88%91%E5%90%8C%E5%8F%A6%E4%B8%80%E5%80%8B%E5%A5%B3%E4%BB%94%E5%82%BE%E8%A8%88/2026 HTTP/1.1" 301 158 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36"
172.20.209.164 - - [19/Sep/2017:09:22:05 +0800] "GET /t/%E7%94%B7%E5%8F%8B%E8%83%8C%E4%BD%8F%E6%88%91%E5%90%8C%E5%8F%A6%E4%B8%80%E5%80%8B%E5%A5%B3%E4%BB%94%E5%82%BE%E8%A8%88/2026 HTTP/1.1" 301 158 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36"
172.20.209.164 - - [19/Sep/2017:09:22:05 +0800] "GET /t/%E7%94%B7%E5%8F%8B%E8%83%8C%E4%BD%8F%E6%88%91%E5%90%8C%E5%8F%A6%E4%B8%80%E5%80%8B%E5%A5%B3%E4%BB%94%E5%82%BE%E8%A8%88/2026 HTTP/1.1" 301 158 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36"
172.20.209.164 - - [19/Sep/2017:09:22:05 +0800] "GET /t/%E7%94%B7%E5%8F%8B%E8%83%8C%E4%BD%8F%E6%88%91%E5%90%8C%E5%8F%A6%E4%B8%80%E5%80%8B%E5%A5%B3%E4%BB%94%E5%82%BE%E8%A8%88/2026 HTTP/1.1" 301 158 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36"
172.20.209.164 - - [19/Sep/2017:09:22:05 +0800] "GET /t/%E7%94%B7%E5%8F%8B%E8%83%8C%E4%BD%8F%E6%88%91%E5%90%8C%E5%8F%A6%E4%B8%80%E5%80%8B%E5%A5%B3%E4%BB%94%E5%82%BE%E8%A8%88/2026 HTTP/1.1" 301 158 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36"
172.20.209.164 - - [19/Sep/2017:09:22:05 +0800] "GET /t/%E7%94%B7%E5%8F%8B%E8%83%8C%E4%BD%8F%E6%88%91%E5%90%8C%E5%8F%A6%E4%B8%80%E5%80%8B%E5%A5%B3%E4%BB%94%E5%82%BE%E8%A8%88/2026 HTTP/1.1" 301 158 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36"
172.20.209.164 - - [19/Sep/2017:09:22:05 +0800] "GET /t/%E7%94%B7%E5%8F%8B%E8%83%8C%E4%BD%8F%E6%88%91%E5%90%8C%E5%8F%A6%E4%B8%80%E5%80%8B%E5%A5%B3%E4%BB%94%E5%82%BE%E8%A8%88/2026 HTTP/1.1" 301 158 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36"

Regards,
Ivan


(Kane York) #2

This is the slug=encoded redirect loop problem, right?


#3

Thanks for the reply! Yet I am not sure, any idea how to fix it?

PS: Worth a mention, if you remove the slug, it still redirect loops you.




EDIT: Just tried all the options, seems not helpful enough :cry:


(Joshua Rosenfeld) #4

This certainly does appear to be the slug=encoded redirect loop problem. The current workaround requires two steps:

  1. Change slug generation method to none
  2. Null out the slug column in the database.

#5

May I know how to null out the slug column? I know there is a postgre database, but not really familiar with that tho :confounded:


(Joshua Rosenfeld) #6

@riking @fefrei either of you familiar with database manipulation?


(Felix Freiberger) #7

So far, I’ve always avoided writing to the database without the protective Ruby layer in between!

I’d try something like…

sudo /var/discourse/launcher enter app
rails c
Topic.all.each{ |t| t.slug = nil; t.save! };

…but I know that this is unnecessarily slow, and I’m not even sure it’ll work at all :wink:


(Kane York) #8

Yeah. The only guaranteed workaround for now is to change the slug generation method back to none / ascii.

edit: Faster way to null out the slug column:

Topic.exec_sql("UPDATE topics SET slug = NULL")


(Felix Freiberger) #9

Oh, I didn’t want to suggest skipping that – that was just my try at nulling out the slug column :joy:


(Sam Saffron) #10

@tgxworld now that rails 5.1 is out can you confirm this infinite redirect bug is gone ?

On local change slug generation method to encoded, create a chinese title, go to topic, hit refresh.


(Alan Tan) #12

I followed the steps you mentioned and am not running into any form of redirect.

@lifehome Can you try upgrading to latest and see if you can still reproduce the problem? Thanks!