Opened 15 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 dmorissette, 15 years ago

Milestone: 5.4 release

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.

comment:2 by tomkralidis, 15 years ago

Cc: assefa added
Owner: changed from mapserverbugs to tomkralidis
Status: newassigned

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 tomkralidis, 15 years ago

How are you encoding the umlaut? I'm having different effects from copy/paste-ing an umlaut from various inputs

comment:4 by sholl, 15 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.

in reply to:  4 ; comment:5 by tomkralidis, 15 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?

in reply to:  5 comment:6 by sholl, 15 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.

comment:7 by tomkralidis, 15 years ago

Milestone: 5.4 release6.0 release

Pushing to 6.0

Note: See TracTickets for help on using tickets.