[eluser]Unknown[/eluser]
(this is a manual repost from EE's dev forum, because this is probably a more appropriate place)
I decided I should probably get other people's opinion before filing an official bug report, so here I am.
I have noticed that putting a single query string element on the end of a URL causes a 404, but adding multiple elements (joined with an &) works correctly.
After doing some hunting around I've discovered that in the case of it failing, the single query string element is set as the URI string. If that element matches a template group/page then it will load that page, otherwise it will 404.
This led me to take a look at where and how the URI string var is set (in _fetch_uri_string() in URI.php, ~ line 69). I discovered this line:
Code:
if (is_array($_GET) && count($_GET) == 1 && trim(key($_GET), '/') != '')
The count($_GET) of course being the culprit in this case. If there is only 1 element then it does something different and "weird".
The intention here is "it is simplest just to build the URI from the zero index of the $_GET array", so if we have a single value, then use it as the page.
This is all well and good, especially if you are wanting to avoid the query string which is the CI/EE thing, but for there to be a difference between ?var1=foo and ?var1=foo&var2=bar is not helpful.
My suggestion therefore is to check for a value to the element to see whether this is a page or a variable, rather than simply grabbing the key. Something like:
Code:
if (is_array($_GET) && count($_GET) == 1 && trim($_GET[key($_GET)]) == '' && trim(key($_GET), '/') != '')
Interestingly, this would also fix the need for EE to subclass _fetch_uri_string() to obtain the session variable so CI doesn't use it as the page "/S/"
Thoughts? Is this is a valid bug (and fix) worth reporting?
