0

I installed zoo-project from sources (latest) on both a Ubuntu 16.04 VM and docker container.

I also have a few python scripts that are already used on a production environnement, with no problem.

A direct call to zoo_loader.cgi with same parameters works fine : my output file is created with expected results.

But when I try to run them through my installation, the http request always return an error :

 wget "http://127.0.0.1:8080/cgi-bin/zoo_loader.cgi?SERVICE=WPS&VERSION=1.0.0&REQUEST=execute&IDENTIFIER=someIdentifier&DataInputs=layer=layer1;fields=code,libelle,geom;filter=1=1;format=CSV;srid='EPSG:4326';requester=locasito&ResponseDocument=resultat@asReference=true&storeExecuteResponse=false&status=false" 

[Fri Jun 15 10:05:25.213873 2018] [cgi:trace1] [pid 4596:tid 139811310495488] util_script.c(628): [client 10.0.2.2:54658] Status line from script 'zoo_loader.cgi': 200 OK
[Fri Jun 15 10:05:25.213940 2018] [deflate:trace1] [pid 4596:tid 139811310495488] mod_deflate.c(724): [client 10.0.2.2:54658] Not compressing (no Accept-Encoding: gzip)
[Fri Jun 15 10:05:25.213954 2018] [http:error] [pid 4596:tid 139811310495488] [client 10.0.2.2:54658] AH02429: Response header name '2018-06-15 10' contains invalid characters, aborting request

the direct cgi call :

root@host:/usr/lib/cgi-bin# ./zoo_loader.cgi "SERVICE=WPS&VERSION=1.0.0&REQUEST=execute&IDENTIFIER=someIdentifier&DataInputs=layer=layer1;fields=code,libelle,geom;filter=1=1;format=CSV;srid='EPSG:4326';requester=locasito&ResponseDocument=resultat@asReference=true&storeExecuteResponse=false&status=false"

With matching response :

2018-06-15 10:14.27 SQL: select source_table as source, source_filter as filter from admin.layer where code = 'layer1' 
2018-06-15 10:14.27 SOURCE : gc.layer1
2018-06-15 10:14.27 FILTER: 3
2018-06-15 10:14.27 K3
2018-06-15 10:14.27 SQL : select code,libelle,geom from gc.layer1 where 1=1
2018-06-15 10:14.41 OUTPUTS : None
Access-Control-Allow-Headers: text/*
Content-Type: text/xml; charset=UTF-8
Status: 200 OK

<?xml version="1.0" encoding="UTF-8"?>
<wps:ExecuteResponse xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:wps="http://www.opengis.net/wps/1.0.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsExecute_response.xsd" service="WPS" version="1.0.0" xml:lang="en-US" serviceInstance="http://127.0.0.1/zoo/">
  <wps:Process wps:processVersion="2">
    <ows:Identifier>someIdentifier</ows:Identifier>
    <ows:Title>Some Identifier Title</ows:Title>
  </wps:Process>
  <wps:Status creationTime="2018-06-15T10:14:41Z">
    <wps:ProcessSucceeded>The service "someIdentifier" ran successfully.</wps:ProcessSucceeded>
  </wps:Status>
  <wps:ProcessOutputs>
    <wps:Output>
      <ows:Identifier>resultat</ows:Identifier>
      <ows:Title>fichier zip </ows:Title>
      <ows:Abstract>some data of interest</ows:Abstract>
      <wps:Data/>
    </wps:Output>
  </wps:ProcessOutputs>
</wps:ExecuteResponse>

According to apache error.log, it looks like the cgi response is directly set as the output http header... (Response header name '2018-06-15 10' contains invalid characters)...

I've tried to change apache DEBUG level (though I didn't expect it to make it run, but in order to have more info), encode the url, add a "headers" section in zoo-project "main.cfg" (adding *Access-Control-Allow-Headers=text/** )... but none fixed my problem.

The apache2 installation is quite basic : I just enabled the serve-cgi-bin.conf.

Since it is already running under a production environment, I should be able to find informations there, but I was not able to find any difference (related to my problem) that would explain the issue.

The zoo-project installation looks find otherwise : the getCapabilities works fine, and returns a correct response. This may come from my script (but then what makes it run on some other platform?)... basically I don't know where I should look to find some clues on how to understand (and fix!) this issue

Any idea?

  • It looks like an issue due to standard output, error redirection. Is it possible that your service mixup stderr and stdout? – Gérald Fenoy Aug 1 '18 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.