$_GET contains unknown/unwanted index on every request

Question

Here's an odd one I haven't encountered before. A Laravel 4 site I was working on was recently deployed to a production server running IIS/PHP 5.5.11. Everything seemed great until I started posting forms. I started receiving errors such as:

Next exception 'Illuminate\Database\QueryException' with message 'SQLSTATE[42S22]: Column not found: 1054 Unknown column '/admin/settings/1' in 'field list' (SQL: update `settings` set `updated_at` = 2015-07-17 08:40:41, `/admin/settings/1` =  where `id` = 1)' in C:\{application_directory}\vendor\laravel\framework\src\Illuminate\Database\Connection.php:625

After some digging, I discovered that the PHP $_GET superglobal variable contains the path, as an index, on every page request in my application. For example, I dumped out the index view of my Settings admin page and received:

Array
(
    [/admin/settings] => 
)

Naturally, as I use Laravel's Input::all() on all form posts which pulls in a combination of both the $_GET/$_POST vars and therefore when it attempts to run the update query, an additional index (without a value) is being passed.

Any ideas? I've checked into IIS's rewrite module, PHP settings, performed a bunch of Google searches to get additional information and I'm running out of options.

Answer 1

I guess the nature of simply asking the question helped move my mind in the right direction. In any case, the answer to this was in the URL Rewrite settings in IIS's web.config. Turns out the general rewrite rule setup was entered in as follows:

<action type="Rewrite" url="/index.php?/{R:1}" appendQueryString="false" />

I was looking over all of the rewrite rules (my development/testing servers all use Apache & mod_rewrite so this was different to me). Finally, I discovered this super helpful question here on SO with regard to setting up laravel on IIS7

Comparing their setup to this one, I noticed a discrepancy in my above mentioned line, namely the ?. It became instantly obvious to me that the url rewriting was causing the injection of this particular index because of that.

Anyway, thanks for the sounding board SO!