Hey all,
Consider a WFS request like this:
<GetFeature...>
posted to the URL:
http://your-geoserver/geoserver/wfs
Now imagine that the <GetFeature...> element didn't have the service="WFS" attribute that it's SUPPOSED to have.
The person has specified that they want to send the request to the wfs (see the /geoserver/wfs path) and they're sending a GetFeature request, so should we be nice and figure out that they meant to send that request to the wfs? If they go so far as to do this:
http://your-geoserver/geoserver/wfs/getfeature
then we currently do the 'nice' thing. It's just the first case I laid out that we don't do anything nice. Actually, we throw a nullpointer exception (=> 500 error) so whatever the decision we'll need to do something 'nicer' here.
Consider that there's also the burden of 'forward porting' this nice-ness. Maybe we're nice in 1.5.x, but the request probably wouldn't work in 1.6.x, no matter what.
So the question is:
A) Be nice to users with malformed requests, and do our best to interpret their mangled XML, no matter how totally mangled it is.
B) Be less nice to users with malformed requests, and provide a nice exception that indicates why we couldn't handle their request.
Thoughts? I guess I'd probably be a jerk and say that B is better.
--saul
Hi Saul,
I am with you on this. I think that we should try to be as lax as
possible when dispatching requests. However as we all know the specs
aren't so forgiving and test these sorts of things in cite.
So we have had this notion of "cite conformance hacks" for a while.
Ideally we should set up the dispatcher with a cite flag and when its
not set be lax about stuff like missing service and version parameters.
But when set throw the exception.
So to answer your questions, my take is this. Do A when the cite flag is
not set, and do B when it is set.
Does that make any sense?
-Justin
Farber, Saul (ENV) wrote:
Hey all,
Consider a WFS request like this:
<GetFeature...>
posted to the URL:
http://your-geoserver/geoserver/wfs
Now imagine that the <GetFeature...> element didn't have the service="WFS" attribute that it's SUPPOSED to have.
The person has specified that they want to send the request to the wfs (see the /geoserver/wfs path) and they're sending a GetFeature request, so should we be nice and figure out that they meant to send that request to the wfs? If they go so far as to do this:
http://your-geoserver/geoserver/wfs/getfeature
then we currently do the 'nice' thing. It's just the first case I laid out that we don't do anything nice. Actually, we throw a nullpointer exception (=> 500 error) so whatever the decision we'll need to do something 'nicer' here.
Consider that there's also the burden of 'forward porting' this nice-ness. Maybe we're nice in 1.5.x, but the request probably wouldn't work in 1.6.x, no matter what.
So the question is:
A) Be nice to users with malformed requests, and do our best to interpret their mangled XML, no matter how totally mangled it is.
B) Be less nice to users with malformed requests, and provide a nice exception that indicates why we couldn't handle their request.
Thoughts? I guess I'd probably be a jerk and say that B is better.
--saul
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
A) Be nice to users with malformed requests, and do our best to interpret their mangled XML, no matter how totally mangled it is.
B) Be less nice to users with malformed requests, and provide a nice exception that indicates why we couldn't handle their request.
+1 for B too - in general we need to improve the error reporting, and encouraging bad behaviour will only make it harder to keep working when we change things, since we'll no longer just have the specs for guidance, but all the known and unknown bad behaviour we rely on.
That said, if very common platforms have specific limitations, we could consider a workaround, until such time as they fix the problem, and after that start throwing an error advising people to upgrade the client.
RA
--saul
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
One other idea might be to have a wfs 'reflector'. In the WMS we have wms/reflect I think we call it, which is super forgiving with lots of defaults. Perhaps we could have a similar thing for wfs, if you're a user just wanting to post requests and try things out you can use that, if you're writing client code you probably shouldn't be using the reflector.
C
Justin Deoliveira wrote:
Hi Saul,
I am with you on this. I think that we should try to be as lax as
possible when dispatching requests. However as we all know the specs
aren't so forgiving and test these sorts of things in cite.
So we have had this notion of "cite conformance hacks" for a while.
Ideally we should set up the dispatcher with a cite flag and when its
not set be lax about stuff like missing service and version parameters.
But when set throw the exception.
So to answer your questions, my take is this. Do A when the cite flag is
not set, and do B when it is set.
Does that make any sense?
-Justin
Farber, Saul (ENV) wrote:
Hey all,
Consider a WFS request like this:
<GetFeature...>
posted to the URL:
http://your-geoserver/geoserver/wfs
The person has specified that they want to send the request to the wfs (see the /geoserver/wfs path) and they're sending a GetFeature request, so should we be nice and figure out that they meant to send that request to the wfs? If they go so far as to do this:
http://your-geoserver/geoserver/wfs/getfeature
then we currently do the 'nice' thing. It's just the first case I laid out that we don't do anything nice. Actually, we throw a nullpointer exception (=> 500 error) so whatever the decision we'll need to do something 'nicer' here.
Consider that there's also the burden of 'forward porting' this nice-ness. Maybe we're nice in 1.5.x, but the request probably wouldn't work in 1.6.x, no matter what.
A) Be nice to users with malformed requests, and do our best to interpret their mangled XML, no matter how totally mangled it is.
B) Be less nice to users with malformed requests, and provide a nice exception that indicates why we couldn't handle their request.
--saul
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Rob Atkinson ha scritto:
A) Be nice to users with malformed requests, and do our best to interpret their mangled XML, no matter how totally mangled it is.
B) Be less nice to users with malformed requests, and provide a nice exception that indicates why we couldn't handle their request.
+1 for B too - in general we need to improve the error reporting, and encouraging bad behaviour will only make it harder to keep working when we change things, since we'll no longer just have the specs for guidance, but all the known and unknown bad behaviour we rely on.
That said, if very common platforms have specific limitations, we could consider a workaround, until such time as they fix the problem, and after that start throwing an error advising people to upgrade the client.
I agree on B, have better error reporting. Otherwise people will start
building apps that don't rely on standards, but on our workaround, and
will have trouble making them talk with other servers (see for example
QGis, that will only talk WFS with MapServer afaik).
A reflector may be nice, provided it's clear it's something totally
out of standard, for your convenience, etc. That is, make it clear you
can use it be simplify coding tasks. On that point of view, I'd see
a reflector as a good idea on GET requests, but I'm dubious on POST
ones where you have an XSD that mandates a certain structure (it's not
like GET does not have a specified form, but it's not as machine
checkable, explicit, and XML ones).
Cheers
Andrea