GeoServer

double encoding of special characters in WFS service exceptions

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.1.2, 2.2.x
  • Component/s: WFS
  • Labels:
    None
  • Number of attachments :
    1

Description

When I do this:

throw new WFSException("\"foo\" & <bar>");

The client gets this:

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
  xsi:schemaLocation="http://www.opengis.net/ows http://localhost:8080/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
  <ows:Exception exceptionCode="NoApplicableCode">
    <ows:ExceptionText>&amp;quot;foo&amp;quot; &amp;amp; &amp;lt;bar&amp;gt;</ows:ExceptionText>
  </ows:Exception>
</ows:ExceptionReport>

But should get this:

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
  xsi:schemaLocation="http://www.opengis.net/ows http://localhost:8080/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
  <ows:Exception exceptionCode="NoApplicableCode">
    <ows:ExceptionText>"foo" &amp; &lt;bar&gt;</ows:ExceptionText>
  </ows:Exception>
</ows:ExceptionReport>

I can fix this by calling OWSUtils.dumpExceptionMessages (DefaultServiceExceptionHandler.java line 77) with xmlEscape false, but I haven't checked to see what else this breaks.

This is using the trunk@16179.

Activity

Hide
Tim Schaub added a comment -

Handle character entities in exception text.

Show
Tim Schaub added a comment - Handle character entities in exception text.
Hide
Tim Schaub added a comment -

I've attached a patch that I think addresses the issues. Since the encoder handles character entities, I think it makes sense that the DefaultServiceException handler always call OwsUtils.dumpExceptionMessages with xmlEscape false. The tests in the attached patch show how special characters are not round-tripped unless xmlEscape is false.

Changing this, the other DefaultServiceException tests fail. I think this is due to r9240 (came with GEOS-1936). Only if xmlEscape is true is msg appended, otherwise t.next() is appended. This causes issue when !t.hasNext().

Thanks for any review.

Show
Tim Schaub added a comment - I've attached a patch that I think addresses the issues. Since the encoder handles character entities, I think it makes sense that the DefaultServiceException handler always call OwsUtils.dumpExceptionMessages with xmlEscape false. The tests in the attached patch show how special characters are not round-tripped unless xmlEscape is false. Changing this, the other DefaultServiceException tests fail. I think this is due to r9240 (came with GEOS-1936). Only if xmlEscape is true is msg appended, otherwise t.next() is appended. This causes issue when !t.hasNext(). Thanks for any review.
Hide
Andrea Aime added a comment -

Hum yeah, the patch looks good, thanks for adding tests. Do you have/want commit rights? Or maybe Justin can just commit it for you?

Show
Andrea Aime added a comment - Hum yeah, the patch looks good, thanks for adding tests. Do you have/want commit rights? Or maybe Justin can just commit it for you?
Hide
Justin Deoliveira added a comment -

Patch applied to trunk and 2.1.x. Thanks Tim!

Show
Justin Deoliveira added a comment - Patch applied to trunk and 2.1.x. Thanks Tim!
Hide
Andrea Aime added a comment -

Mass transition all resolved issue that did not see any further comment in the last month to closed status

Show
Andrea Aime added a comment - Mass transition all resolved issue that did not see any further comment in the last month to closed status

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: