Opened 10 years ago

Closed 9 years ago

#3444 closed defect (fixed)

OGC: allow user to specify default version of the spec supported

Reported by: assefa Owned by: assefa
Priority: normal Milestone: 6.0 release
Component: WMS Server Version: unspecified
Severity: normal Keywords: OGC version
Cc: stephan.holl@…, jmckenna, strk@…, mko, yves.moisan@…, schpidi, dmorissette


For example in WMS if the version parameter is not set, MapServer usually defaults to the latest supported version (1.3.0). The idea is to have a web level metadata that can be used to set the default version

Change History (16)

comment:1 Changed 10 years ago by sholl

Cc: stephan.holl@… added

comment:2 Changed 10 years ago by jmckenna

Cc: jmckenna added

comment:3 Changed 10 years ago by strk

Cc: strk@… added

+1 1.3.0 seems not well supported so I'd prefer my deplois to avoid that, unless explicitly requested by clients.

comment:4 Changed 10 years ago by strk

For the record, I was having problems with both gvSIG and QuantumGIS, altough the qgis ones haven't figured out yet (disappeared on new build - could have been due to impossibility to find client side projection data)

comment:5 Changed 10 years ago by mko

Cc: mko added

comment:6 Changed 9 years ago by yvesm

Cc: yves.moisan@… added

comment:7 Changed 9 years ago by yvesm

I wonder if MapServer could send a response header that is meaningful. For now, it sends 200 OK whatever the version number passed in the request is, provided it is of one of two forms : x.y or x.y.z. The client gets an image back, but has no way to tell if the version number was taken care of or not. Problem is I can't find a response header that would be a mix of 200 (Ok you got your image) and 404 (can't find VERSION number you sent) and 30? (redirecting to default VERSION) or some such. Ideas ?

comment:8 Changed 9 years ago by yvesm

The Expect request-header field is used to indicate that particular server behaviors are required by the client. (

Expect VERSION and values = {...,1.1.1,1.3.0} ?

Problem is its a request header and it would mean changing the WMS spec I guess.

The most likely candidate for a response header where the VERSION number used could be stored is Accept-Ranges. However this only "allows the server to indicate its acceptance of range requests for a resource" so maybe there is a way for MS to tell the client it will accept a range of values for the VERSION parameter, but it won't tell the client what VERSION number it actually used in a specific response.

I'll stop commenting now 'cos I'm lost ;-)

comment:9 Changed 9 years ago by Schpidi

Cc: schpidi added

comment:10 Changed 9 years ago by dmorissette

FWIW, a default version setting makes sense only for GetCapabilities?.

Other requests (GetMap?, GetFeatureInfo?, etc.) all require an explicit VERSION to be specified and MapServer already uses that value to construct its response.

See also my explanation in

comment:11 Changed 9 years ago by dmorissette

Cc: dmorissette added

comment:12 Changed 9 years ago by yvesm

comment:13 Changed 9 years ago by assefa

metadata wms_getcapabilities_version adn wfs_getcapabilities_version that can be used to default the capabilities document. If not set the latest supported version will be used. WMS Exception is also returned when doing getmap/getfeatureinfo for non supported versions

comment:14 Changed 9 years ago by assefa

forgot to indicate the revisions: r10864 and for the docs: r10865

comment:15 Changed 9 years ago by sholl


are there any other blockers in this issue? Will this be in 6.0?



comment:16 Changed 9 years ago by assefa

Resolution: fixed
Status: newclosed

yes it is going to be in 6.0. Closing since It was committed a while ago.

Note: See TracTickets for help on using tickets.