MapScript PHP SWIG OWSRequest loadParams problem

[jpchenel]

Expected behavior and actual behavior.

Hi,

We've made a migration from Mapserver 7.4.4 to 8.0.1. We use mapscript to handle the request. We have made some change to switch to SWIG API.

Before, we were using the mapscript.OWSRequest->loadParams() to retrieve all the query string parameters, but I don’t seem to work anymore.

Steps to reproduce the problem.

Create a file getMap.php:

require_once("/usr/lib/php/20210902/mapscript.php");
msIO_installStdoutToBuffer();

$r = new OWSRequest();
$r->loadParams();
$r->NumParams; // return 0

Call the script:

http://hostname/mapscripts/getMap.php?map=mymap&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&FORMAT=image%2Fpng&TRANSPARENT=true&LAYERS=wmspoint&SRS=EPSG%3A32198&CRS=EPSG%3A32198

Has a workaround, I use:

$query = $_SERVER['QUERY_STRING'];
$r = new OWSRequest();
$r->loadParamsFromURL($query);
$r->NumParams; // return 9

Operating system

22.04.2 LTS (GNU/Linux 5.15.0-79-generic x86_64)

MapServer version 8.0.1 PROJ version 8.2 GDAL version 3.4 OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUPPORTS=OGCAPI_SERVER SUPPORTS=FASTCGI SUPPORTS=GEOS SUPPORTS=PBF INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE INPUT=FLATGEOBUF

[geographika]

What web server are you using? It seems as though the CGI QUERY_STRING environment variable is empty (and the CGI environment can be different from the server environment).

It could also be related to the tightening of security in 8.0 where QUERY_STRING is not allowed in a CGI call - see 442d763
However this all happens in mapserv.exe so not sure why MapScript would be affected.

[jpchenel]

Dear Seth,

Web server is Apache 2.4.52

Thank you,

[jmckenna]

@jpchenel good find, I can reproduce this on Windows with MS4W 5.0 (today's MapServer-main, Apache, PHP, SWIG). In my case here is the error displayed in the browser:

Fatal error: Uncaught Exception: loadParams(): Web application error. No query information to decode. QUERY_STRING is set, but empty. Stack trace: #0 : OWSRequest->loadParams() #1 {main} thrown

[jmckenna]

Also, if I print out the variables for the Environment (_ENV), and the Server (_SERVER), through PHP, both give an empty QUERY_STRING, after initiating OWSRequest() :

GATEWAY_INTERFACE => CGI/1.1
SERVER_PROTOCOL => HTTP/1.1
REQUEST_METHOD => GET
QUERY_STRING =>  

[jmckenna]

Possibly-related comment, from #6284:

For example loadParams() is in the cgiutil.c, which is in libmapserver and not mapserv binary, and loadParams() is invoked by main() with a getenv2==NULL, which means that getenv2=&msGetEnv is used, which finally uses getenv(). So REQUEST_METHOD retrieving should fail according to the above theory.

(I'm sure someone will reply here jeff it's not at all related but it sure helps me understand and know where to look for these getenv/getenv2 calls)

I wonder why loadParams has problems in Apache with PHP with SWIG...

[sdlime]

Does Python behave similarly or is this PHP-specific?

[geographika]

Does Python behave similarly or is this PHP-specific?

I don't think this is an issue with MapScript itself, but more the CGI setup/environment used to run MapScript.
A simple Python test works correctly:

import os
import mapscript

os.environ["REQUEST_METHOD"] = "GET"
os.environ["QUERY_STRING"] = "SERVICE=WMS&VERSION=1.1.0&REQUEST=GetCapabilities"
req = mapscript.OWSRequest()
req.loadParams()
print(req.NumParams) # 3

The environment available to MapScript depends on how it is run. I'd typically run Python MapScript under a Python server behind another server with a reverse-proxy.
Dumping out all the environment variables and values in the PHP script may show what is available - maybe the "QUERY_STRING" is available under another name?

[geographika]

Also, if I print out the variables for the Environment (_ENV), and the Server (_SERVER), through PHP, both give an empty QUERY_STRING, after initiating OWSRequest() :

GATEWAY_INTERFACE => CGI/1.1
SERVER_PROTOCOL => HTTP/1.1
REQUEST_METHOD => GET
QUERY_STRING =>  

The above explains the issue. PHP may need to access this differently as discussed in http://people.w3.org/~dom/archives/2004/07/testing-php-pages-with-query_string/

I don't understand how the original post from @jpchenel workaround works though - $_SERVER['QUERY_STRING']; should be empty here too:

$query = $_SERVER['QUERY_STRING'];
$r = new OWSRequest();
$r->loadParamsFromURL($query);
$r->NumParams; // return 9

[jmckenna]

@geographika thanks, your message helped me. Embarrassingly, I was passing the variables in the url incorrectly. Now I see proper QUERY_STRING values for both _ENV and _SERVER, and, I get the correct value of NumParams. (I had also incorrect validation stuff happening with my MAP path) When I fixed all that, I get exactly as you for the Python MapScript test. In other words, now that I understand it all, I can no longer reproduce this on Windows, with the main branch.

$r = new OWSRequest();
$r->loadParams();
echo $r->NumParams;

called through: http://127.0.0.1/quickmap-loadparams.php?MAP=/ms4w/apps/local-demo/local.map&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetCapabilities

Num Params: 4

@jpchenel can you re-try your tests with the main branch?

[jmckenna]

@jpchenel if it's useful, I am using SWIG 4.1.1 and PHP 8.2.8