Add [mapserv_url] template tag

[dmorissette]

The template parser currently lacks a mechanism to return the complete URL of the mapserv CGI. (This came up while working on ticket #3549)

We could add a [mapserv_url] (better name welcome) template tag that would use msOWSGetOnlineResource() (mapows.c) or a modified version of it to return the complete mapserv CGI URL, including protocol prefix ( http:// vs  https://), hostname, optional port number, and script_name (full path to mapserv CGI).

Note that msOWSGetOnlineResource() also includes the map=... param in the URL if it was explicitly provided by the caller (i.e. not set vis MS_MAPFILE env. var.), and finally it terminates the URL with either "?" or "&" so that you are ready to add more params to it.

The only issue with this automatic URL detection is if you are working behind a proxy: in this case you get the internal URL and not the proxy's public URL. To address this, msOWSGetOnlineResource() checks the ows_onlineresource metadata and uses its value in precedence if it is set. We would need a similar (and more generic) setting for the new [mapserv_url] tag.

[sdlime]

Only other tag names I can think of is [binary], [program], [exe] or something along those lines. I was thinking of not including the host and protocol in that context thinking there might be times where you might just want the program name and not the full url. You could then do:

[protocol]://[host][program]

and so on...

Steve

[dmorissette]

Separate tags as in [protocol]://[host][program] could be useful for specific apps, but it requires handling in the template (possibly using JavaScript?) of optional [port] and map=[map] which are not always explicitly stated in a mapserv URL (it may not hurt to always make port explicit, but the mapfile path is sometimes hidden and set via env vars).

For the needs of the generic template required by ticket #3549 (RFC-63), we really need a single tag that includes protocol, hostname, optional port, mapserv path, and even embeds the mapfile path if it was explicitly set in URL (i.e. not passed via env. vars.), all this terminated by a "?" or "&" ready to append QUERY_STRING params to it ... this is what msOWSGetOnlineResource() already does for WMS so I adapt my proposal above to suggest that we call this tag [mapserv_onlineresource] and that it call msOWSGetOnlineResource() directly... I know this is WMS lingo and may feel a bit foreign for traditional mapserv CGI users, but that describes well what the tag does: it provides a complete online resource URL referring to a given service (CGI+mapfile) to which you can start adding parameters without worrying about optional components of the URL ([port] and [map] are not always explicit).

msOWSGetOnlineResource() also checks the *_onlineresource metadata and uses that value if it is set. The [mapserv_onlineresource] would also follow the same logic: in both the WMS and the traditional CGI case it would check for wms_onlineresource and ows_onlineresource.

We could also provide separate tags for each component of the full URL for more specific uses by CGI apps that know what they are doing, and in this case I'd propose that we name them based on the names used by the CGI spec:

[server_protocol]://[server_name]:[server_port][script_name]

Would that work for you Steve?

[sdlime]

Yup, that works for me.... Although several of the tags (host/port) currently exist and should be deprecated.

Steve