Opened 14 years ago

Closed 13 years ago

#3571 closed defect (fixed)

Duplicated XML and HTML errors from WFS GetFeature

Reported by: warmerdam Owned by: assefa
Priority: normal Milestone:
Component: WFS Server Version: svn-trunk (development)
Severity: normal Keywords:
Cc: aboudreault, tomkralidis

Description (last modified by warmerdam)

If I do the following with a simple wfs service: 

./mapserv QUERY_STRING="map=test.map&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&OUTPUTFORMAT=GML2"

I get: 

Content-type: text/xml

<?xml version='1.0' encoding="ISO-8859-1" ?>
<ServiceExceptionReport version="1.2.0" xmlns="http://www.opengis.net/ogc" xmlns
:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.
opengis.net/ogc http://schemas.opengis.net/wfs/1.0.0/OGC-exception.xsd">
  <ServiceException code="MissingParameterValue" locator="typename">
msWFSGetFeature(): WFS server error. Incomplete WFS request: TYPENAME parameter 
missing
  </ServiceException>
</ServiceExceptionReport>
Content-type: text/html

<HTML>
<HEAD><TITLE>MapServer Message</TITLE></HEAD>
<!-- MapServer version 5.7-dev OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP OUT
PUT=SVG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=WMS
_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WCS_SERVER SUPPORTS=SOS
_SERVER SUPPORTS=FASTCGI SUPPORTS=THREADS SUPPORTS=GEOS INPUT=OGR INPUT=GDAL INP
UT=SHAPEFILE -->
<BODY BGCOLOR="#FFFFFF">
msWFSGetFeature(): WFS server error. Incomplete WFS request: TYPENAME parameter 
missing
</BODY></HTML>

on "stdout". The code producing this looks like: 

  if (paramsObj->pszTypeName==NULL && paramsObj->pszFeatureId == NULL)
  {
      msSetError(MS_WFSERR, 
                 "Incomplete WFS request: TYPENAME parameter missing", 
                 "msWFSGetFeature()");
      return msWFSException(map, "typename", "MissingParameterValue", paramsObj->pszVersion);
  }

The problem seems to be that msWFSException() is properly incorporating the error message in the xml exception but it is also getting reissued as html further up the call stack. I assume this is undesired behavior but I'm hesitant to fiddle with stuff too much without knowing how this was intended to work.

Thoughts? Would you like me to investigate clearing the error stack in msWFSException() or otherwise tracking that html errors should not be issued after a failed wfs action?

Attachments (1)

test.zip​ (15.9 KB ) - added by warmerdam 14 years ago.
mapfile and data to test with.

Download all attachments as: .zip

Change History (13)

comment:1 by warmerdam, 14 years ago

Description: modified (diff)

by warmerdam, 14 years ago

Attachment: test.zip​ added

mapfile and data to test with.

comment:2 by assefa, 14 years ago

Cc: aboudreault added

I think this might be related to #3554, I was wondering why we had to clear the error stack and made the comment without doing tests. We might want to reopen #3554

comment:3 by dmorissette, 14 years ago

And for the record I agree that the duplicate error msg is a bug and needs to be fixed.

comment:4 by assefa, 14 years ago

Owner: changed from mapserverbugs to assefa

comment:5 by tomkralidis, 14 years ago

Cc: tomkralidis added

comment:6 by aboudreault, 14 years ago

I've taken a look..... we would need to determine if msOWSDispatch() have been called from php/mapscript or not in ms*Exception function. But it's not possible at the moment. Also, we cannot only ignore errors in mapserv.c since msOWSDispatch() can set a non ows exception errors and we have to report them. A simple workaround would be to add new error types, like MS_WFSEXCEPTION. That way, we could check in mapserv.c if the error type is a ows exception, and not printing it if so. Any other suggestions?

comment:7 by warmerdam, 14 years ago

My thought was that we would introduce a "has been reported" flag in the errorObj. Then stuff like msWFSException() could mark the errors reported and we could check this before reporting errors in mapserv.c. This way the error stack is still preserved for php inspection, but we can avoid double-reporting.

comment:8 by aboudreault, 14 years ago

Could be a good idea. However, when we are in ms*Exception(), the error has already been reported. We could pass through the error list to get the last error added, set it as has been reported ... but it is not really safe. What if ms*Exception() is called without set an error via msSetError, so the last error would be set to reported even if it shouldn't. Daniel mentionned something about a static flag which could be used in mapscript and used in the ms*Exception functions to not reset the list if set.

comment:9 by warmerdam, 14 years ago

I don't follow your point about the error having been reported when we get into msWFSException(). It has been already set with msSetError(), but it hasn't been pushed through to stdout. I see msWFSException() calls msWriteErrorXML() - couldn't that mark any errorObj it reports as reported?

The php flag to not reset error stacks would work, but it seems like a hack to me. Ideally, I'd rather solve the more general issue of knowing when an error has actually been reported to the user / web client / application.

comment:10 by aboudreault, 14 years ago

Resolution: → fixed
Status: new → closed

The errors are automatically set as reported in msWriteError() and msWriteErrorXML() functions.

Fixed and committed in r10643.

comment:11 by warmerdam, 13 years ago

Resolution: fixed
Status: closed → reopened

Reopening for similar problems with SOS - for example msautotest/wxs/sos_se8.xml. I'll dig in and see if I can extend the pattern to this service.

comment:12 by warmerdam, 13 years ago

Resolution: → fixed
Status: reopened → closed

double reporting of SOS errors fixed (r10696) - msautotest/wxs/sos.map passes again.

Note: See TracTickets for help on using tickets.