Welcome to the Question2Answer Q&A. There's also a demo if you just want to try it out.
+3 votes
1.4k views
in Q2A Core by
edited by

Previously, my website was functioning correctly, but now I am unable to access URLs with whitespace in the tags or usernames. It appears that the Q2A script is not replacing whitespace with a plus sign (+) in the tag URLs, causing a 'Forbidden' error when trying to access those pages. How can I fix this issue?

UPDATE:
I found that htaccess option in url structure is not OK but I doubt how it automatically changed from OK to blank and I have not even changed anything on server side.

Mod rewrite options is already enabled and htaccess file is also already available with default settings.

But still first URL structure is not OK and I have the problem accessing the URL mentioned above.

Please anyone help me fix the issue.

Q2A version: 1.8.6
by
Actually the issue is this many sites are getting affected due to this, please look into it

https://stackoverflow.com/questions/75684314/ah10411-error-managing-spaces-and-20-in-apache-mod-rewrite
by
Hi @pupi1985, I found the reason causing the issue, the issue occurred due to your patch which I followed and changes to my code.

Here is the url of your patch:
https://github.com/q2a/question2answer/pull/966/commits/bdda461de2edd6ac0cc5377a8e5f78af5f703a23
by
Actually you suggested to replace urlencode() function with rawurlencode() and rawurlencode() function is not replacing white space between tag names with plus sign(+).

While urlencode() was replacing space with plus sign which was working as expected.

When I rollback your patch my issue got resolved.
by
Strictly speaking, you never answered my request, which was "a link to a live site showing this issue to see the actual URL being generated". This is a must for me to continue with any analysis.

Answering your comment about the urlencode/rawurlencode concern, in short, urlencode is non-standard and there is no reason to use it nowadays.

Using rawurlencode does not leave a space, as you implied, but rather replaces it with a %20. If that is not happening, then there is another issue, which is unrelated to this (most likely, a plugin or a corehack intefering with the URL generation).

So if you can show me the live page, I will confirm if this is the case or not.

1 Answer

+1 vote
by

I understand this issue should now be fixed by v1.8.8. Or, actually, fixed by updating the .htaccess file with the `B` letter in this line:

RewriteRule ^.*$ index.php?qa-rewrite=$0&%{QUERY_STRING} [B,L]

I think you should:

  1. Upgrade to 1.8.8, if you haven't already
  2. Roll back your changes
  3. Apply this patch (which is a subset of your changes, if I guessed them correctly)
...