Opened 17 years ago

Closed 17 years ago

Last modified 16 years ago

#2025 closed defect (fixed)

Attempts to process WFS request without WFS compiled into mapserv generates the following error "Web application error. No template provided"

Reported by: mzanfardino@… Owned by: warmerdam
Priority: high Milestone:
Component: WFS Client Version: 4.10
Severity: normal Keywords:
Cc:

Description (last modified by dmorissette)

Attempts to process WFS request without WFS compiled into mapserv generates the
following error "Web application error. No template provided"

Change History (8)

comment:1 by fwarmerdam, 17 years ago

Status: newassigned
Summary: Attempts to process WFS request without WFS compiled into mapserv generates the following error "Web application error. No template provided" Attempts to process WFS request without WFS compiled into mapserv generates the following error "Web application error. No template provided"
It is my opinion that MapServer should actually generate an error message
in msOWSDispatch() for requested services that we don't have compiled in.

As things stand it can be quite hard for users to establish why their
WxS request isn't getting handled properly.


comment:2 by tomkralidis, 17 years ago

If possible, I would lean towards being able to decipher whether a service type
is just not supported, or is supported but not compiled in.

As far as old URLs with "service=...", I wonder how many cases there would be
where this was part of the URL and the value of service= was a string which is
an unsupported service type, so I would initially say that I would not back port
this.

comment:3 by dmorissette, 17 years ago

Cc: dmorissette@… added

comment:4 by tomkralidis, 17 years ago

Cc: tom.kralidis@… added

comment:5 by fwarmerdam, 17 years ago

Resolution: fixed
Status: assignedclosed
This got a bit more complicated than I expected. 

It turns out that the functions msWMSDispatch(), msWFSDispatch() and 
so forth are always compiled in even if the service is not available, and
these functions issue an appropriate error in that case.  

So I modified msOWSDispatch() to actually call them unconditionally.

However, for mapserv.c to know whether it was supposed to report the error
to stdout I had to modify all the OWS services exception methods to 
clear the error stack after issuing exceptions.  An error still left
on the stack after msOWSDispatch() returns gets reported by mapserv.c
now.

This is a sort of risky change!  We never used to require the exceptions
functions to clear the error stack, so I am worried there could be
some sort of surprising side effect.  I'm not quite sure what though.


Files affected: mapserv.c, mapows.c, mapwfs.c, mapwms.c, mapwcs.c, mapogcsos.c

Changes only in development head ... way to risky to backport. 

comment:6 by fwarmerdam, 17 years ago

Cc: Steve.Lime@… added
Resolution: fixed
Status: closedreopened
OK, serious issues with changes.  It turns out functions like 
msSOSDispatch() always issue the error if they are not configured in. 

I have backed out the change in mapows.c for now.  I will revisit this
issue and try to come up with a proper fix.

comment:7 by fwarmerdam, 17 years ago

Resolution: fixed
Status: reopenedclosed
modified msOWSDispatch() to issue an error if a service is requested but is
not compiled in.  

comment:8 by dmorissette, 16 years ago

Description: modified (diff)

The fix for this committed in r5911 was reading the VERSION parameter instead of SERVICE.

Fixed in r7450 in trunk for 5.2.

Note: See TracTickets for help on using tickets.