Special chars (&, /, ?, maybe more) wrong rewritten by mod_rewrite when clean urls enabled [#23685]

Okay, I looked around for this problem, but couldn't find it. When you use a &, /, or ? as a value in a freeform list (i.e. under "Stuff you like" put "Kavalier & Clay, Farhenheit 9/11, Dude? Where's my car.) and when you click on those values to see other users with the same interests it will cut off at the special char, saying "Other users who are interested in Kavalier ." or "Farhenheit 9" or "Dude" instead of the whole thing.

I looked in profiles.module to try a figure it out, but couldn't. I tried a urlencode/decode, but when the url is profile/profile_interests_books/Kavalier%20&%20Clay arg(2) actually equals "Kavalier " so it might be in the arg() code.

lines 63:

function profile_browse() {

  $name = arg(1);
  $value = arg(2);

line ~208:

            // This $value should be urlencoded right?
            $fields[] = $browse ? l($value, "profile/$field->name/$value") : check_plain($value);

Comments

Comment #1

Steven CreditAttribution: Steven commented 1 June 2005 at 04:32

You are right: those values should be urlencoded().

I don't get your problem with the ampersand though... on my PHP, urlencode('&') returns %26: the ampersand is escaped like any other meaningful URL character (: / \ + ? & = ).

urldecoding is done automatically by PHP for any query variables, arg() simply fetches them as a normal string and doesn't need to do anything else.

Ps: Next time, please set the status to 'patch' and attach a real patch generated with the diff tool.

Comment #2

RobRoy CreditAttribution: RobRoy commented 1 June 2005 at 16:01

Well, I tried the urlencode, but that didn't work (at least for me). So I would've done a patch, but I couldn't figure out how to make it work right. Did just a simple urlencode($value) work for you? I had run into an obstacle, I can't remember what now though.

Comment #3

RobRoy CreditAttribution: RobRoy commented 1 June 2005 at 21:03

Okay, well I remember now why I didn't do the patch. Changing it to

$fields[] = $browse ? l($value, "profile/$field->name/" . urlencode($value)) : check_plain($value);

does not fix the problem. I did this change on my site http://www.theseniorbachelor.com/ and you can see my profile at http://www.theseniorbachelor.com/user/1

Click on Kavalier & Clay, and you'll see what I mean. The link goes to http://www.theseniorbachelor.com/profile/profile_interests_books/Kavalie... which is correctly urlencoded, but in the profile_browse function, if you do a var_dump($value); at the top it will not show the correct value for arg(2).

So it seems as if this is a bug in the arg() code or in the mod_rewrite or something. Because I even put in a var_dump($_GET['q']); and it returns string(43) "profile/profile_interests_general/Kavalier " which is really strange.

You see what I mean?

Comment #4

RobRoy CreditAttribution: RobRoy commented 1 June 2005 at 21:06

Okay, I just turned Clean URLs off to see if it works and it does. So it is definitely a bug with mod_rewrite and these rules

  # Rewrite current-style URLs of the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

So the % in the %26 must be messing with the rules. I'm not too good with that stuff so not sure why.

Comment #5

Robin Monks CreditAttribution: Robin Monks commented 3 June 2005 at 13:49

I've tried every PHP trick I know, to no avail. I'm also positive it's Mod_Rewrites problem.

Robin

Comment #6

RobRoy CreditAttribution: RobRoy commented 3 June 2005 at 17:29

Component:

profile.module

» other

I'm changing this to Component: other. This is a problem with mod_rewrite that should be checked out by someone with better Apache skills.

Comment #7

RobRoy CreditAttribution: RobRoy commented 16 July 2005 at 00:11

Version:

4.6.0

» 4.6.2

This is an important issue. Basically any special chars that url encode to %26 or whatever are screwing up major things in Drupal. Now when I do a search for interpreter's the resulting page is search/node/interpreter%27s and I get the message The word s was not included because it is too short. But the search results matches the whole word interpreter's which is weird.

I still believe this to be an issue with clean_urls enabled and mod_rewrite. Any thoughts?

Comment #8

toemaz CreditAttribution: toemaz commented 17 October 2005 at 12:11

Title:

Special chars (&, /, ?, maybe more) use in freeform lists not working

» Special chars (&, /, ?, maybe more) wrong rewritten by mod_rewrite when clean urls enabled

Did anyone found a fix for this issue already? It is indeed an important issue. But it seems the solution is not easy since the last ticket was from the 16th of July. :-(

Just searching on drupal.org using any of those special characters, is enough to reproduce the problem...

Comment #9

toemaz CreditAttribution: toemaz commented 17 October 2005 at 13:16

Seems Drupal is not the only distribution having this problem. Check out:
http://mail.wikipedia.org/pipermail/mediawiki-l/2005-June/005814.html

Is there someone with Apache experience who might help on this?

Comment #10

magico CreditAttribution: magico commented 19 August 2006 at 15:20

Version:

4.6.2

» 4.6.9

Still unresolved?

Comment #11

magico CreditAttribution: magico commented 24 August 2006 at 16:19

Version:

4.6.9

» 4.7.3

Do the following search in google: AT&T site:drupal.org
Now doing the same using the search module in drupal: AT&T

It seems that this bug is here in the most recent version (I suppose drupal.org is using 4.7.3)

Comment #12

RobRoy CreditAttribution: RobRoy commented 24 August 2006 at 16:35

The search thing is another issue as they strip out & from search. So a search for Att&ttt works as those are both 3 chars.

This was an issue more in the profile module, but it appears fixed in 4.7.3. If you look at my profile and click on ro/ck & roll%rol!li?e the header of the resulting page prints out "ro/ck & roll%rol!li?e" fine, when I reported this issue it would cut off before the %.

But I still think we should be encoding forward slashes as that will separate the arg().