Opened 16 years ago
Last modified 15 years ago
#2831 assigned defect
WFS 1.1.0 breaks when OWS_ABSTRACT contains umlauts
Reported by: | sholl | Owned by: | tomkralidis |
---|---|---|---|
Priority: | normal | Milestone: | 6.0 release |
Component: | WFS Server | Version: | 5.2 |
Severity: | normal | Keywords: | |
Cc: | assefa |
Description
in MapServer 5.2.0 it is not allowed to enter german umlauts (äöü) into the OWS_ABSTRACT METADATA field in a layer-element when you request WFS 1.1.0. Using WFS 1.0.0 instead works.
This also applies to the WEB METADATA OWS_ABSTRACT block. WMS does not have this problem. It seems that there is some encoding needed.
Perhaps someone could have a look at it
Change History (7)
comment:1 by , 16 years ago
Milestone: | → 5.4 release |
---|
comment:2 by , 16 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
I can reproduce (what I think is) the issue on trunk. When an umlaut is used, WFS 1.0.0 outputs correctly, but WFS 1.1.0 does not (output is an incomplete XML document). Tested using a GetCapabilities request against both versions.
The difference is that the WFS 1.1.0 code uses mapowscommon.c to output common metadata, whereas WFS 1.0.0 does not. mapwfs.c uses msEncodeHTMLEntities against the value when printing it out (which I'm not sure is making the difference here). mapwfs11.c uses mapowscommon.c, which does as Dan says.
Using msEncodeHTMLEntities in mapowscommon.c does not solve the issue. Looking deeper.
comment:3 by , 16 years ago
How are you encoding the umlaut? I'm having different effects from copy/paste-ing an umlaut from various inputs
follow-up: 5 comment:4 by , 16 years ago
My encoding is iso-8859-1.
My METADATA looks like this: "OWS_ABSTRACT" "my shine umlauts: öäüß"
as said by tomkralidis the XML-GetCaps-Doc is incorrect. You can reproduce this by using curl as a client.
follow-up: 6 comment:5 by , 16 years ago
Replying to sholl:
My encoding is iso-8859-1.
My METADATA looks like this: "OWS_ABSTRACT" "my shine umlauts: öäüß"
as said by tomkralidis the XML-GetCaps-Doc is incorrect. You can reproduce this by using curl as a client.
Wierd. When I copy/paste your text above into ows_abstract, to a mapfile in my terminal (on a MacBook), I get no error. When I do the same on a Windows box, I get an error.
Perhaps it's the way your terminal or mapfile text editor is setup?
comment:6 by , 16 years ago
Replying to tomkralidis:
Replying to sholl:
My encoding is iso-8859-1.
My METADATA looks like this: "OWS_ABSTRACT" "my shine umlauts: öäüß"
as said by tomkralidis the XML-GetCaps-Doc is incorrect. You can reproduce this by using curl as a client.
Wierd. When I copy/paste your text above into ows_abstract, to a mapfile in my terminal (on a MacBook), I get no error. When I do the same on a Windows box, I get an error.
Perhaps it's the way your terminal or mapfile text editor is setup?
I could reproduce this on Windows (ms4w 2.3.0) and also in GNU/Linux (selfcompiled MS 5.2.0), and it is always failing. It is not only the terminal, also the Browser shows an 'incomplete XML-doc' warning.
On Win I used notepad++ as editor, on GNU/Linux I use vim, and never had any setup-problems at all. I assume that the parser just bails out.
BTW, this also applies for [WFS|OWS]_*-entries where one can insert strings when requesting WFS in Version 1.1.0.
What doesn't work exactly? Is it your WFS client that complains or MapServer itself? Any error message?
MapServer should just paste the value from the metadata entry into the XML response... it doesn't try to do any encoding conversion.
I'd suggest you raise this issue in the mapserver-users since others may have dealt with this issue before.