[Geoserver-devel] WMS GetCapabilities

Justin_Deoliveira · May 31, 2006, 8:05am

Hi all,

When you do a get capabilities against WMS in GeoServer you get Request elemetns that look like:

<Request>
<GetCapabilities>
...
<Get>
<OnlineResource xlink:type="simple" xlink:href="http://localhost:8080/geoserver/wms?"/>
</Get>
....

Since VERSION and SERVICE are required paramters on a request shouldnt the above be:

-Justin

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Chris_Holmes1 · May 31, 2006, 8:26am

I'm pretty positive no. In the caps document you just put the location of the base url on to which you apply the required params. It's the clients job to put on the required params. For example they may want a different VERSION, 1.3 for example. If we had a dispatcher for WMS and WFS, then their base url would be the same, and the service param would come in to play. Also note this is one of the things cite can test, and since we pass the tests we must be compliant.

Chris

Justin Deoliveira wrote:

Hi all,

When you do a get capabilities against WMS in GeoServer you get Request elemetns that look like:

<Request>
<GetCapabilities>
...
<Get>
<OnlineResource xlink:type="simple" xlink:href="http://localhost:8080/geoserver/wms?"/>
</Get>
....

Since VERSION and SERVICE are required paramters on a request shouldnt the above be:

<OnlineResource xlink:type="simple" xlink:href="http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1"/>

-Justin

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Justin_Deoliveira · May 31, 2006, 9:02am

So it looks like the resource url has to indicate to the server which service is being called somehow. In the old system we used a special WMS dispatcher mapped to the /geoserver/wms path to do it.

With a single dispatcher that doesn't work. It means the dispatcher has to analyze the context path and figuring out what the request is from the context path. Interesting.

So my question is now: Does it become any less correct to use the SERVICE parameter in the resource url to indicate to the dispatcher what the service is as opposed to using the context path to do it.

-Justin

Chris Holmes wrote:

I'm pretty positive no. In the caps document you just put the location of the base url on to which you apply the required params. It's the clients job to put on the required params. For example they may want a different VERSION, 1.3 for example. If we had a dispatcher for WMS and WFS, then their base url would be the same, and the service param would come in to play. Also note this is one of the things cite can test, and since we pass the tests we must be compliant.

Chris

Justin Deoliveira wrote:

Hi all,

When you do a get capabilities against WMS in GeoServer you get Request elemetns that look like:

<Request>
<GetCapabilities>
...
<Get>
<OnlineResource xlink:type="simple" xlink:href="http://localhost:8080/geoserver/wms?"/>
</Get>
....

Since VERSION and SERVICE are required paramters on a request shouldnt the above be:

<OnlineResource xlink:type="simple" xlink:href="http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1"/>

-Justin

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Justin_Deoliveira · May 31, 2006, 9:13am

I think I found the answer. The spec says that:

the online resource url ends with "?" OR ends with "&" and contains "?", which means throwing the SERVICE parameter on is syntactically valid. Just ran cite with the small modification and they are happy.

-Justin

Justin Deoliveira wrote:

So it looks like the resource url has to indicate to the server which service is being called somehow. In the old system we used a special WMS dispatcher mapped to the /geoserver/wms path to do it.

With a single dispatcher that doesn't work. It means the dispatcher has to analyze the context path and figuring out what the request is from the context path. Interesting.

So my question is now: Does it become any less correct to use the SERVICE parameter in the resource url to indicate to the dispatcher what the service is as opposed to using the context path to do it.

-Justin

Chris Holmes wrote:

I'm pretty positive no. In the caps document you just put the location of the base url on to which you apply the required params. It's the clients job to put on the required params. For example they may want a different VERSION, 1.3 for example. If we had a dispatcher for WMS and WFS, then their base url would be the same, and the service param would come in to play. Also note this is one of the things cite can test, and since we pass the tests we must be compliant.

Chris

Justin Deoliveira wrote:

Hi all,

When you do a get capabilities against WMS in GeoServer you get Request elemetns that look like:

<Request>
<GetCapabilities>
...
<Get>
<OnlineResource xlink:type="simple" xlink:href="http://localhost:8080/geoserver/wms?"/>
</Get>
....

Since VERSION and SERVICE are required paramters on a request shouldnt the above be:

<OnlineResource xlink:type="simple" xlink:href="http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1"/>

-Justin

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Efren_Serra · May 31, 2006, 7:38pm

Justin,

For a GET, the xlink:ref should be http://hostname[:port]/geoserver/wms?
For a POST, the xlink:ref should be http://hostname[:port]/geoserver/wms

The client application should attach the SERVICE and SERVICE key value pairs
to the request, whether it is via GET or POST.

v/r,
Efren

-----Original Message-----
From: geoserver-devel-admin@lists.sourceforge.net
[mailto:geoserver-devel-admin@lists.sourceforge.net]On Behalf Of Justin
Deoliveira
Sent: Wednesday, May 31, 2006 10:04 AM
To: Geoserver-devel
Subject: [Geoserver-devel] WMS GetCapabilities

Hi all,

When you do a get capabilities against WMS in GeoServer you get Request
elemetns that look like:

<Request>
<GetCapabilities>
...
<Get>
<OnlineResource xlink:type="simple"
xlink:href="http://localhost:8080/geoserver/wms?"/>
</Get>
....

Since VERSION and SERVICE are required paramters on a request shouldnt
the above be:

-Justin

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel