[Geoserver-devel] wrong WFS endpoints in WMS DescribeLayer response

GeoServer GeoServer Developer
1

issue a DescribeLayer request against a vector layer, results in something like:

<LayerDescription name="topp:states"
wfs="http://localhost:8080/geoserver/wfs/WfsDispatcher?&quot;
owsURL="http://localhost:8080/geoserver/wfs/WfsDispatcher?&quot;
owsType="WFS">

(note the /wfs/WfsDispatcher endpoint instead of just /wfs)

The class responsible for it actually has a comment:
DescribeLayerTransformer, line 153:

// REVISIT: not sure why we need WfsDispatcher, "wfs?" should suffice imho
owsUrl = buildURL(baseURL, "wfs/WfsDispatcher", null, URLType.SERVICE);

First question: can we get rid of /WfsDispatcher or does someone know
a reason not to?

Second question: the endpoint actually work, so does /wfs/foo and
/wfs/bar and so on. Isn't that wrong?

Cheers,
Gabriel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

2

On Tue, Sep 20, 2011 at 11:14 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

issue a DescribeLayer request against a vector layer, results in something like:

<LayerDescription name="topp:states"
wfs="http://localhost:8080/geoserver/wfs/WfsDispatcher?&quot;
owsURL="http://localhost:8080/geoserver/wfs/WfsDispatcher?&quot;
owsType="WFS">

(note the /wfs/WfsDispatcher endpoint instead of just /wfs)

The class responsible for it actually has a comment:
DescribeLayerTransformer, line 153:

// REVISIT: not sure why we need WfsDispatcher, "wfs?" should suffice imho
owsUrl = buildURL(baseURL, "wfs/WfsDispatcher", null, URLType.SERVICE);

First question: can we get rid of /WfsDispatcher or does someone know
a reason not to?

I believe it's fine to remove it. Afaik the code in that class was written back
at the time when the actual wfs dispatcher was at that URL.

Second question: the endpoint actually work, so does /wfs/foo and
/wfs/bar and so on. Isn't that wrong?

I guess it migth have been made for backwards compatibility for
whoever was still
calling wfs/WfsDispatcher.
We could make the dispatcher be more strict, but maybe we need to add a flag
to re-enable the old behavior for those that cannot fix the existing
client applications?
Another worry is, do we have anything else in GeoServer linking back to the
wrong url, and thus relying on this tolerant behavior to actually work?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

3

Well, the only mention to WfsDispatcher is
org.vfny.geoserver.servlets.Dispatcher
and it has an interesting comment:

//JD: kill this class

WfsDispatcher is gone, and neither it nor
org.vfny.geoserver.servlets.Dispatcher are mapped in web.xml anymore.
Which makes the reference to WfsDispatcher in DescribeLayer look even
more like a leftover.

Second question: the endpoint actually work, so does /wfs/foo and
/wfs/bar and so on. Isn't that wrong?

I guess it migth have been made for backwards compatibility for
whoever was still
calling wfs/WfsDispatcher.
We could make the dispatcher be more strict, but maybe we need to add a flag
to re-enable the old behavior for those that cannot fix the existing
client applications?

The reason why /wfs/WfsDispatcher and /wfs/foo work is because the wfs
module's applicationContext.xml routes /wfs/* to the current
Dispatcher, so I think we're good anyways?

Another worry is, do we have anything else in GeoServer linking back to the
wrong url, and thus relying on this tolerant behavior to actually work?

looks like not.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

4

On Sat, Sep 24, 2011 at 7:55 PM, Gabriel Roldan <groldan@anonymised.com1501…> wrote:

Well, the only mention to WfsDispatcher is
org.vfny.geoserver.servlets.Dispatcher
and it has an interesting comment:

//JD: kill this class

WfsDispatcher is gone, and neither it nor
org.vfny.geoserver.servlets.Dispatcher are mapped in web.xml anymore.
Which makes the reference to WfsDispatcher in DescribeLayer look even
more like a leftover.

Second question: the endpoint actually work, so does /wfs/foo and
/wfs/bar and so on. Isn’t that wrong?

I guess it migth have been made for backwards compatibility for
whoever was still
calling wfs/WfsDispatcher.
We could make the dispatcher be more strict, but maybe we need to add a flag
to re-enable the old behavior for those that cannot fix the existing
client applications?

The reason why /wfs/WfsDispatcher and /wfs/foo work is because the wfs
module’s applicationContext.xml routes /wfs/* to the current
Dispatcher, so I think we’re good anyways?

Another worry is, do we have anything else in GeoServer linking back to the
wrong url, and thus relying on this tolerant behavior to actually work?

looks like not.

I think I misunderstood what you proposed.
I’m ok with killing the class, I’m worried about making the dispatching
more strict and throw errors if one tries to access the wfs using
a url like wfs/WFSDispatcher.
If we want to become more strict, I’m still ok with it, provided we have
a flag to get back the more loose behavior for backwards compatibility

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

5

In general I would like to see us continue to support the old url… unless it simply becomes too onerous to do so. I wonder if we could fix this by tweaking the dispatcher mappings. So rather than mapping to /wfs/* we map to “wfs”, and then specifically to “/wfs/WfsDispatcher”.

I would be ok with an option to support the old behaviour… although I would rather just see us deprecate the old endpoints (emitting a warning) and then removing them in the next major release. Rationale being that I can’t imagine many people use the old endpoints (although I could be wrong) so going through the work of adding the flag, documenting it, etc… seems a lot of work for not much gain.

$0.02

On Sun, Sep 25, 2011 at 2:16 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sat, Sep 24, 2011 at 7:55 PM, Gabriel Roldan <groldan@anonymised.com…> wrote:

Well, the only mention to WfsDispatcher is
org.vfny.geoserver.servlets.Dispatcher
and it has an interesting comment:

//JD: kill this class

WfsDispatcher is gone, and neither it nor
org.vfny.geoserver.servlets.Dispatcher are mapped in web.xml anymore.
Which makes the reference to WfsDispatcher in DescribeLayer look even
more like a leftover.

Second question: the endpoint actually work, so does /wfs/foo and
/wfs/bar and so on. Isn’t that wrong?

I guess it migth have been made for backwards compatibility for
whoever was still
calling wfs/WfsDispatcher.
We could make the dispatcher be more strict, but maybe we need to add a flag
to re-enable the old behavior for those that cannot fix the existing
client applications?

The reason why /wfs/WfsDispatcher and /wfs/foo work is because the wfs
module’s applicationContext.xml routes /wfs/* to the current
Dispatcher, so I think we’re good anyways?

Another worry is, do we have anything else in GeoServer linking back to the
wrong url, and thus relying on this tolerant behavior to actually work?

looks like not.

I think I misunderstood what you proposed.
I’m ok with killing the class, I’m worried about making the dispatching
more strict and throw errors if one tries to access the wfs using
a url like wfs/WFSDispatcher.
If we want to become more strict, I’m still ok with it, provided we have
a flag to get back the more loose behavior for backwards compatibility

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

6

On Mon, Sep 26, 2011 at 4:02 PM, Justin Deoliveira <jdeolive@anonymised.com.1501…> wrote:

In general I would like to see us continue to support the old url… unless it simply becomes too onerous to do so. I wonder if we could fix this by tweaking the dispatcher mappings. So rather than mapping to /wfs/* we map to “wfs”, and then specifically to “/wfs/WfsDispatcher”.

I would be ok with an option to support the old behaviour… although I would rather just see us deprecate the old endpoints (emitting a warning) and then removing them in the next major release. Rationale being that I can’t imagine many people use the old endpoints (although I could be wrong) so going through the work of adding the flag, documenting it, etc… seems a lot of work for not much gain.

+1, works for me

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

7

On Mon, Sep 26, 2011 at 11:11 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Mon, Sep 26, 2011 at 4:02 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

In general I would like to see us continue to support the old url...
unless it simply becomes too onerous to do so. I wonder if we could fix this
by tweaking the dispatcher mappings. So rather than mapping to /wfs/* we map
to "wfs", and then specifically to "/wfs/WfsDispatcher".
I would be ok with an option to support the old behaviour... although I
would rather just see us deprecate the old endpoints (emitting a warning)
and then removing them in the next major release. Rationale being that I
can't imagine many people use the old endpoints (although I could be wrong)
so going through the work of adding the flag, documenting it, etc... seems a
lot of work for not much gain.

+1, works for me

So that would be like emitting a warning on 2.1.x if the
/wfs/WfsDispatcher endpoint is hit, but killing it on trunk?

I'm not sure if getting rid of the /wfs/* dispatcher mapping would
have any other side effect like in for virtual services or so?

Cheers,
Gabriel.