XF 2.2 "Start Conversation" link results in 404 depending on username

[RippC]

Just found this problem this morning, and I'm at a loss as to its cause.

I found a couple of users, for which the "start conversation" link (/conversations/add?to=username) results in a hard 404 error. Other usernames work just fine. I can't seem to find a pattern in the usernames (granted I haven't found that many) that causes this. I can start a convo with the user by leaving the username off that URL, then typing it into the "to" field on that page just fine, so I don't think its related to the user's permissions or anything.

My nginx logs don't show anything but a 404, and so far can't find any other error log msg to help.

This is on PHP 7.4.3 FPM, NGINX 1.18.0, MariaDB 10.3.31 on Ubuntu 20.04.3, XF 2.2.7

Even a hint to where to start would be helpful. Tried big G but not much luck with this specific issue. TIA.

 

[Lukas W.]

If the 404 is triggered on the server level (unstyled, mostly blank page with text), then it might be an issue with a rewrite rule or similar. As soon as it hits XenForo, you should see the XenForo 404 error page instead (looks roughly like this), regardless of what error is thrown (for the most part including internal server errors).

 

[RippC]

there's the thing, its just the default nginx 404 page, not the soft 404 page from XF.

 

[RippC]

noticed you're from TH, this is using UIX 2 also... if it matters.

 

[Paul B]

What is the URL shown at the bottom left of the browser when hovering over the start conversation link for an affected member?

Does it work in the default style?

 

[RippC]

Just tried with the default XF style, same thing.

the URL's look identical in both cases /conversations/add?to=username

I can go there from one user profile and it works great, these couple of users I've found (and now I can't find the second one again ) no dice.

The juicy part of my nginx site conf looks like this.

try_files $uri $uri/ /index.php?$uri&$args;

which IIRC is the standard thing... No idea how long it's been going on, just went to msg a user and I'm like "oh. ok?"

 

[rdn]

Nginx -T?

 

[Paul B]

I don't use Nginx so I'm not able to test.

I presume it works fine with FURLs disabled.

The manual has the default conf values here: https://xenforo.com/docs/xf2/options/#nginx

 

[RippC]

Nginx -T?

scouring through that I noticed this:

# First attempt to serve request as file, then
    # as directory, then fall back to displaying a 404.
    if ($request_uri ~* ".(ico|css|js|gif|jpe?g|png)$") {
            expires 30d;
                access_log off;
                add_header Pragma public;
                add_header Cache-Control "public";
                break;
        }

coincidentally, the user name ends in "CSS" ... so, I'm guessing this directive is being applied since the last 3 chars in the suspect username are CSS, but the dot should keep that from happening, right? Did I F that line up somehow? Needs to be \ escaped? Has to be this bc there's no mention of this 404 in the access logs. And it looks like cloudflare is re-writing cache headers, but I'm gonna test a few things out.

 

[Paul B]

coincidentally, the user name ends in "CSS" ... so, I'm guessing this directive is being applied since the last 3 chars in the suspect username are CSS

I just tested here (which uses nginx) with a couple of members whose user names begin and end with css, and even one which is only css, and it worked fine.

 

[RippC]

yeah, that's it. I created a user with ICO as the last 3 chars, same effect.

And yep, escaping that . with \ did the trick.

Thanks for the -T pointer, wouldn't have found it unless I had to peruse that. Kept glossing over it in my editor lol. Thanks again.