Request returns null

Hello,

I think you should be using the "input" or "query" methods to access the querystring value (at least if you're using Laravel 7):

$items = $request->input('items'); // Retrieves values from the entire request payload
$items = $request->query('items'); // Retrieves values from the query string only

Regards.

Hi. Thank you for responding and showing these additional methods to work with the request. I am using Laravel 5.8, and I have now tested both "input" and "query" methods to be working on my local development environment, but unfortunately the same code returns null when working from actual web server.

It's definitely got me stumped.

Is all of your data uploaded to the live mySQL database.

Hello. Thank you for responding. Yes, I have the data uploaded to the database however at this time I am unable to even access the query string from the request it would seem. I have altered the controller to simply dump the contents and that returns null:

public function table(Request $request)
{
	$items = $request->items;
	dd($items);

	return view('table', compact('items'));
}

So when I access URL domain.com/table?items=50 for example when I am working local it will return "50" but when try the same URL from live server it returns null instead.

Double check seems like it's not the correct URL or something. Or you may need to clear your route cache, because that should work especially if it worked on local.

Try clearing the route cache php artisan route:clear as previously suggested. It's also possible your web server might not be passing the query strings correctly to Laravel. Which web server are you using?

Hi. Thank you for the suggestions. I have ran the php artisan route:clear with no effect I'm afraid.

I am running an Nginx web server on a Digital Ocean droplet. Perhaps, it's worth noting that my local dev environment is an Apache web server. I don't know if that matters all that much. I have compared the request headers between them and they are the same with exception of the "Cookie" one which looks different. My knowledge in this area isn't very good though.

@seibzehn Do you have this line somewhere in your NGINX config?

try_files $uri $uri/ /index.php?$query_string;

@flightsimmer668 Please see my Nginx config below. I noticed it has a second server block that must have been added automatically during SSL setup. Wondering if that's intended or could be a problem?

server {
        server_name redacted;
        root /var/www/html/redacted/public;

        add_header X-Frame-Options "SAMEORIGIN";
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Content-Type-Options "nosniff";

        index index.html index.htm index.php;

        charset utf-8;

        location / {
                try_files $uri $uri/ /index.php?$query_string;
        }

        location = /favicon.ico { access_log off; log_not_found off; }
        location = /robots.txt  { access_log off; log_not_found off; }

        error_page 404 /index.php;

        location ~ \.php$ {
                fastcgi_pass unix:/run/php/php7.2-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
                include fastcgi_params;
        }

        location ~ /\.(?!well-known).* {
                deny all;
        }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/redacted/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/redacted/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = redacted) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80;
        server_name redacted;
    return 404; # managed by Certbot
}

I don't see anything wrong with this configuration. Might I suggest tailing the NGINX access log tail -f /var/log/nginx/access.log then initiate your request:

domain.com/table?items=40

and see if in the running log the /table endpoint is printed along with the query parameters ?items=40

If you don't see the query params, then it is likely being filtered out by the web server before it reaches the application.

I don't think this is happening, I cross checked same code on server on both laravel and lumen app both are working fine, try to may be you are hitting "domain.com/table?item=40" insted of "domain.com/table?items=40".

@flightsimmer668 Here is output from the access.log.

[14/May/2020:01:50:38 +0000] "GET /statistics/design/table?items=50 HTTP/1.1" 200 5629 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0"

Looks like it is getting the query string, which I can see in the browser tools as well. I decided to dd($request) and check them both.

Here is a local request:

Request {#43 ▼
  #json: null
  #convertedFiles: null
  #userResolver: Closure($guard = null) {#215 ▶}
  #routeResolver: Closure() {#216 ▶}
  +attributes: ParameterBag {#45 ▶}
  +request: ParameterBag {#51 ▶}
  +query: ParameterBag {#51 ▼
    #parameters: array:2 [▼
      "page" => "1"
      "items" => "40"
    ]
  }
  +server: ServerBag {#47 ▶}
  +files: FileBag {#48 ▶}
  +cookies: ParameterBag {#46 ▶}
  +headers: HeaderBag {#49 ▶}
  #content: null
  #languages: null
  #charsets: null
  #encodings: null
  #acceptableContentTypes: null
  #pathInfo: "/statistics/design/table"
  #requestUri: "/statistics/design/table?page=1&items=40"
  #baseUrl: ""
  #basePath: null
  #method: "GET"
  #format: null
  #session: Store {#254 ▶}
  #locale: null
  #defaultLocale: "en"
  -isHostValid: true
  -isForwardedValid: true
  basePath: ""
  format: "html"
}

Here is one from production:

Request {#43 ▼
  #json: null
  #convertedFiles: null
  #userResolver: Closure($guard = null) {#215 ▶}
  #routeResolver: Closure() {#216 ▶}
  +attributes: ParameterBag {#45 ▶}
  +request: ParameterBag {#51 ▶}
  +query: ParameterBag {#51 ▼
    #parameters: array:1 [▼
      "query_string" => null
    ]
  }
  +server: ServerBag {#47 ▶}
  +files: FileBag {#48 ▶}
  +cookies: ParameterBag {#46 ▶}
  +headers: HeaderBag {#49 ▶}
  #content: null
  #languages: null
  #charsets: null
  #encodings: null
  #acceptableContentTypes: null
  #pathInfo: "/statistics/design/table"
  #requestUri: "/statistics/design/table?page=1&items=40"
  #baseUrl: ""
  #basePath: null
  #method: "GET"
  #format: null
  #session: Store {#254 ▶}
  #locale: null
  #defaultLocale: "en"
  -isHostValid: true
  -isForwardedValid: true
  basePath: ""
  format: "html"
}

Is ModSecurity installed on the server? Not sure if it can drop query parameters, but I had problems with it in the past.

Welp. Of course it was something easy that I should have known. Changes to Nginx config don't take effect until after a reload or restart. I ran the following command and I'm back in business.

sudo service reload nginx

Thank you everyone for the help. I learned some useful things, so much appreciated.