The WFS GetCapabilities put a wrong double & #4622

Closed
aperi2007 opened this Issue Apr 4, 2013 · 15 comments

Projects

None yet

3 participants

@aperi2007

Hi,

I notice that the getcapabilities of a WFS servicewill put a wrong & final in the urls.

An example this url:

web.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmstest&service=WMS&version=1.1.0&REQUEST=GetCapabilities

The xml result is apparently correct in the browser, but if I see it with an editor
I can notice that the urls

like this:
<ows:Get xlink:type="simple" xlink:href="http://www502.regione.toscana.it/cartografia/wmsraster/com.rt.wms.RTmap/wms?map=test&amp;amp;"/>

are all with
a final:
&amp;

Where the second "amp;" is wrong and break the work of many clients.

I'm use a mapserver 6.3-dev version.

@ejn
Contributor
ejn commented Apr 4, 2013

It's not just WFS, also WMS (the URL you supplied)

Looking at the URL reported for the operations, it's not the same as the URL used for the capabilites request (different map parameter, wmstest <-> test). Have you supplied a custom URL with an already entity-encoded & in your mapfile?

@aperi2007

Hi,
The map=test is a wrong type, also the returnd url is wrong, but only because I'm concentrate on the & problem don't notice the wrog url and the wrong map parameter.

Now I correct them ,

The setting I apply is this:

"ows_onlineresource" "http://web.regione.toscana.it/cartografia/wmsraster/com.rt.wms.RTmap/wms?map=wmstest"

And the returned value in the wfs getcapabilities.
is still:

<ows:Get xlink:type="simple" xlink:href="http://web.regione.toscana.it/cartografia/wmsraster/com.rt.wms.RTmap/wms?map=wmstest&amp;amp;"/>
@aperi2007

oops, I notice only now I wrong to report the url.

The correct url to get the WFS getcapablities is this:

http://web.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmstest&service=WFS&version=1.1.0&REQUEST=GetCapabilities

The result seem correct seeing it from a browser, but instead seeeing it on a editor is clear the wrong

<ows:Get xlink:type="simple" xlink:href="http://web.regione.toscana.it/cartografia/wmsraster/com.rt.wms.RTmap/wms?map=wmstest&amp;amp;"/>
@aperi2007

Also I see the bug is onl in the WFS 1.1.0 getcapabilities it is not in the 1.0.0 version.

@ejn
Contributor
ejn commented Apr 5, 2013

Looking at the code, I think I see where this is coming from: WFS 1.0.0 (and other OWS services) just write the capabilities document as text, WFS 1.1.0 uses libxml to build the document using DOM and then write it. For the "old style" method, the script url must be manually encoded, using libxml then that takes care of it but the function msWFSGetCapabilities11 already manually encodes it to script_url_encoded (I guess just copy-and-pasted from the WFS 1.0.0 function).

@aperi2007 do you want to try producing a patch for this yourself? If not then I'll try and hack up a branch for you to test.

@tbonfort
Member
tbonfort commented Apr 5, 2013

@aperi2007 , using curl on your server:

1.1.0:

<ows:Get xlink:type="simple" xlink:href="http://web.regione.toscana.it/cartografia/wmsraster/com.rt.wms.RTmap/wms?map=wmstest&amp;"/>

1.0.0:

<Get onlineResource="http://web.regione.toscana.it/cartografia/wmsraster/com.rt.wms.RTmap/wms?map=wmstest&amp;" />

which both seem correct. The trailing & isn't very elegant, but clients should be able to handle it as it far from invalid.

Does the trailing &amp;amp; , which is clearly invalid, happen when you add the trailing & to the onlineresource metadata?

@aperi2007

Hi,

thx for suggestions.
I try a "patch"

The patch I try is simply to
change from this:

  if ((script_url=msOWSGetOnlineResource(map, "FO", "onlineresource", req)) == NULL
      || (script_url_encoded = msEncodeHTMLEntities(script_url)) == NULL) {
    msSetError(MS_WFSERR, "Server URL not found", "msWFSGetCapabilities11()");
    return msWFSException11(map, "mapserv", "NoApplicableCode", params->pszVersion);
  }

to this

  if ((script_url=msOWSGetOnlineResource(map, "FO", "onlineresource", req)) == NULL
      || (script_url_encoded = script_url) == NULL) {
    msSetError(MS_WFSERR, "Server URL not found", "msWFSGetCapabilities11()");
    return msWFSException11(map, "mapserv", "NoApplicableCode", params->pszVersion);
  }

It seem work as I can see,
but I understand that it very bad patch because I set just

script_url_encoded = script_url .

But I guess this is a dirty solution that most probably someone could remove think it as an error.
:)

@aperi2007

Hi thomas,

the response is now correct because I applied the patch as reported in the
ticket.

#4622

2013/4/5 Thomas Bonfort notifications@github.com

@aperi2007 https://github.com/aperi2007 , using curl on your server:

1.1.0:

<ows:Get xlink:type="simple" xlink:href="http://web.regione.toscana.it/cartografia/wmsraster/com.rt.wms.RTmap/wms?map=wmstest&amp;"/>

1.0.0:

which both seem correct. The trailing & isn't very elegant, but clients
should be able to handle it as it far from invalid.

Does the trailing &amp; , which is clearly invalid, happen when _you_add the trailing
& to the onlineresource metadata?


Reply to this email directly or view it on GitHubhttps://github.com/mapserver/mapserver/issues/4622#issuecomment-15941916
.


Andrea Peri
. . . . . . . . .

qwerty àèìòù

@tbonfort
Member
tbonfort commented Apr 5, 2013
script_url_encoded = script_url

Yes, this clearly isn't the correct solution, I'm even surprised it isn't segfaulting.

@aperi2007

I guess the first part of the IF avoid the script_url_encoded var was null.

2013/4/5 Thomas Bonfort notifications@github.com

script_url_encoded = script_url

Yes, this clearly isn't the correct solution, I'm even surprised it isn't
segfaulting.


Reply to this email directly or view it on GitHubhttps://github.com/mapserver/mapserver/issues/4622#issuecomment-15942699
.


Andrea Peri
. . . . . . . . .

qwerty àèìòù

@ejn ejn added a commit to faegi/mapserver that referenced this issue Apr 5, 2013
@ejn ejn Don't entity-encode URLs used on attributes: libxml2 does this for us…
…. Refs #4622
36cb497
@ejn
Contributor
ejn commented Apr 5, 2013

@aperi2007 thanks for testing that: it confirms that this is the source of the error.

Could you test the branch at https://github.com/faegi/mapserver/tree/wfs11CapabilitiesUrlEntityEncoding ??

@tbonfort
Member
tbonfort commented Apr 5, 2013

@ejn can you base this on 6.2 instead of master once/if you open a pull request for this? thanks.

@ejn
Contributor
ejn commented Apr 5, 2013

@tbonfort OK, will do.

@ejn ejn added a commit to faegi/mapserver that referenced this issue Apr 8, 2013
@ejn ejn + faegi Don't entity-encode URLs used on attributes: libxml2 does this for us…
…. Refs #4622
fcbb210
@ejn ejn was assigned Apr 8, 2013
@tbonfort
Member
tbonfort commented Apr 8, 2013

closed with #4623

@tbonfort tbonfort closed this Apr 8, 2013
@ejn ejn referenced this issue in mapserver/msautotest_DEPRECATED Apr 8, 2013
Closed

Add something to be entity-encoded to custom URL. #19

@tbonfort tbonfort added a commit that referenced this issue Apr 8, 2013
@tbonfort tbonfort update msautotests for #4622 08daada
@tbonfort tbonfort added a commit that referenced this issue Apr 8, 2013
@tbonfort tbonfort update msautotests for #4622 d818868
@tbonfort
Member
tbonfort commented Apr 8, 2013

autotests updated in branch-6-2 and master in mapserver/msautotest_DEPRECATED@ba02510

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment