Hello there:
As you can see, the OGC CITE compliance tests have been failing for the last few days: http://hudson.opengeo.org/hudson/view/cite/job/cite-wfs-1.1-master/761/.
The reason for that is a patch that was submitted for issue GEOS-4011: https://github.com/geoserver/geoserver/pull/168
The problem here lies in the fact that the OGC and the W3C specifications do not agree with each other. According to the OGC, the content type served by GeoServer should be Content-Type: application/xml; subtype=gml/x.x.x, while the W3C says that it should be Content-Type: application/xml; subtype=“gml/x.x.x”
So, given that GeoServer has a so called “Strict CITE compliance” mode, whose value is used to establish the citeCompliant property of the org.geoserver.ows.Dispatcher class, perhaps we could change its behaviour so that it serves Content-Type: application/xml; subtype=gml/x.x.x when the “Strict CITE compliance” mode is enabled and Content-Type: application/xml; subtype=“gml/x.x.x” when it is not. Therefore, the patch in question would become something like this:
//check for SOAP request
if (req.isSOAP()) {
req.getHttpResponse().setContentType(SOAP_MIME);
}
else {
if (!citeCompliant) {
mimeType = mimeType.replaceAll(“(subtype=)(gml/[0-9.]*)”, “$1"$2"”); // fix for [GEOS-4011]
}
req.getHttpResponse().setContentType(mimeType);
}
Care to comment about this?
Best wishes.
–
ni hao ma?
On Tue, Mar 5, 2013 at 3:11 PM, José Manuel Arnesto <kevloral@anonymised.com> wrote:
Hello there:
As you can see, the OGC CITE compliance tests have been failing for the last few days: http://hudson.opengeo.org/hudson/view/cite/job/cite-wfs-1.1-master/761/.
The reason for that is a patch that was submitted for issue GEOS-4011: https://github.com/geoserver/geoserver/pull/168
The problem here lies in the fact that the OGC and the W3C specifications do not agree with each other. According to the OGC, the content type served by GeoServer should be Content-Type: application/xml; subtype=gml/x.x.x, while the W3C says that it should be Content-Type: application/xml; subtype=“gml/x.x.x”
So, given that GeoServer has a so called “Strict CITE compliance” mode, whose value is used to establish the citeCompliant property of the org.geoserver.ows.Dispatcher class, perhaps we could change its behaviour so that it serves Content-Type: application/xml; subtype=gml/x.x.x when the “Strict CITE compliance” mode is enabled and Content-Type: application/xml; subtype=“gml/x.x.x” when it is not. Therefore, the patch in question would become something like this:
Hum… wondering if there are clients around that are as strict as the CITE tests, and would not work if we use the escapes.
Maybe it should be a separate property, one that is, again just maybe, a system property.
On one side that seems cheap, on the other side I’m under the impression that the mime type not being strictly
W3C compliant has not been causing significant issues, makes me actually wonder where that causes problems?
Maybe in some network apparaturs?
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
2013/3/5 Andrea Aime <andrea.aime@anonymised.com…>
On Tue, Mar 5, 2013 at 3:11 PM, José Manuel Arnesto <kevloral@anonymised.com> wrote:
Hello there:
As you can see, the OGC CITE compliance tests have been failing for the last few days: http://hudson.opengeo.org/hudson/view/cite/job/cite-wfs-1.1-master/761/.
The reason for that is a patch that was submitted for issue GEOS-4011: https://github.com/geoserver/geoserver/pull/168
The problem here lies in the fact that the OGC and the W3C specifications do not agree with each other. According to the OGC, the content type served by GeoServer should be Content-Type: application/xml; subtype=gml/x.x.x, while the W3C says that it should be Content-Type: application/xml; subtype=“gml/x.x.x”
So, given that GeoServer has a so called “Strict CITE compliance” mode, whose value is used to establish the citeCompliant property of the org.geoserver.ows.Dispatcher class, perhaps we could change its behaviour so that it serves Content-Type: application/xml; subtype=gml/x.x.x when the “Strict CITE compliance” mode is enabled and Content-Type: application/xml; subtype=“gml/x.x.x” when it is not. Therefore, the patch in question would become something like this:
Hum… wondering if there are clients around that are as strict as the CITE tests, and would not work if we use the escapes.
Maybe it should be a separate property, one that is, again just maybe, a system property.
On one side that seems cheap, on the other side I’m under the impression that the mime type not being strictly
W3C compliant has not been causing significant issues, makes me actually wonder where that causes problems?
Maybe in some network apparaturs?
Cheers
Andrea
Actually, the problem with the mime type not being W3C compliant has arisen because we in the Co-Cities project (http://www.co-cities.eu/) are using a so called Reference Platform to validate the correctness of the several WFS interfaces deployed in the participating cities (I am in charge of the one in Bilbao, Spain) and that tool is complaining about that issue. Some people have resorted to using a “hacked” ows library, but I preferred to adopt a different approach and try to submit a fix to the GeoServer code.
Best wishes.