[Geoserver-users] Wrong port number in get capabilities

GeoServer GeoServer User
1

Hi,

I’ve just noticed that GeoServer seems to be writing port 443 into our get capabilities statements but this is not the SSL port configured for our Tomcat server.

Is there an easy place to set the port numbers so that GeoServer knows which ports it is using or is it easier to just change the port numbers to use the standard ones?

Thanks,

Paul

2

The proxy base url should be used to adjust the output of the capabilities document: https://docs.geoserver.org/latest/en/user/configuration/globalsettings.html#proxy-base-url

···

–
Jody Garnett

3

Hi,

Thanks for getting back to me Jody. After a bit more research I have changed tack on this as the issue is that WFS is not working in QGIS. I’m now investigating whether it might be because the workspace URI are not valid links and QGIS gives up if it gets any 404 responses. Originally these were real links so I’m going to restore that to see if that fixes things but if it does I might put in a patch request on the documentation as I think I saw a message from Andrea on an online thread suggesting the URI should point at a real link if you want to avoid client issues.

Would it not be safer to say that on the documentation as I think it might also have been causing the issues I’m getting when trying to connect via ESRI products as well?

Thanks,

Paul

···

The proxy base url should be used to adjust the output of the capabilities document: https://docs.geoserver.org/latest/en/user/configuration/globalsettings.html#proxy-base-url

–

Jody Garnett

On Sat, 27 Jul 2019 at 02:35, Paul Wittle <paul.wittle@…9945…> wrote:

Hi,

I’ve just noticed that GeoServer seems to be writing port 443 into our get capabilities statements but this is not the SSL port configured for our Tomcat server.

Is there an easy place to set the port numbers so that GeoServer knows which ports it is using or is it easier to just change the port numbers to use the standard ones?

Thanks,

Paul

This e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. It may contain unclassified but sensitive or protectively marked material and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All traffic may be subject to recording and/or monitoring in accordance with relevant legislation. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Dorset Council. Dorset Council does not accept service of documents by fax or other electronic means. Virus checking: Whilst all reasonable steps have been taken to ensure that this electronic communication and its attachments whether encoded, encrypted or otherwise supplied are free from computer viruses, Dorset Council accepts no liability in respect of any loss, cost, damage or expense suffered as a result of accessing this message or any of its attachments. For information on how Dorset Council processes your information, please see www.dorsetcouncil.gov.uk/416433

Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

4

Do you want to try turning on WFS strict checkbox? For a while QGIS 2 behaved much better with that setting on :stuck_out_tongue:

···

–
Jody Garnett

5

Hum,

Thanks for the tip but still no luck even after making the URIs into valid URLs and turning on strict. I’m still getting “Download of feature type failed: Protocol “” is unknown” so perhaps it is a network issue to do with our firewall or something like that. It seems to work if I avoid using the domain names (i.e. routing internally directly to the server name) but I will obviously need to take it up with the QGIS groups rather than this one as it is starting to look like it might be an issue with our security or QGIS rather than my configuration of GeoServer.

Haha, rarely simple when working with our, shall I call it niche, windows deployment.

Thanks,

Paul

···

Do you want to try turning on WFS strict checkbox? For a while QGIS 2 behaved much better with that setting on :stuck_out_tongue:

–

Jody Garnett

On Thu, 1 Aug 2019 at 00:00, Paul Wittle <paul.wittle@…9945…> wrote:

Hi,

Thanks for getting back to me Jody. After a bit more research I have changed tack on this as the issue is that WFS is not working in QGIS. I’m now investigating whether it might be because the workspace URI are not valid links and QGIS gives up if it gets any 404 responses. Originally these were real links so I’m going to restore that to see if that fixes things but if it does I might put in a patch request on the documentation as I think I saw a message from Andrea on an online thread suggesting the URI should point at a real link if you want to avoid client issues.

Would it not be safer to say that on the documentation as I think it might also have been causing the issues I’m getting when trying to connect via ESRI products as well?

Thanks,

Paul

From: Jody Garnett <jody.garnett@…84…>
Sent: 31 July 2019 06:45
To: Paul Wittle <P.Wittle@…7193…>
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Wrong port number in get capabilities

The proxy base url should be used to adjust the output of the capabilities document: https://docs.geoserver.org/latest/en/user/configuration/globalsettings.html#proxy-base-url

–

Jody Garnett

On Sat, 27 Jul 2019 at 02:35, Paul Wittle <paul.wittle@…9945…> wrote:

Hi,

I’ve just noticed that GeoServer seems to be writing port 443 into our get capabilities statements but this is not the SSL port configured for our Tomcat server.

Is there an easy place to set the port numbers so that GeoServer knows which ports it is using or is it easier to just change the port numbers to use the standard ones?

Thanks,

Paul

This e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. It may contain unclassified but sensitive or protectively marked material and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All traffic may be subject to recording and/or monitoring in accordance with relevant legislation. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Dorset Council. Dorset Council does not accept service of documents by fax or other electronic means. Virus checking: Whilst all reasonable steps have been taken to ensure that this electronic communication and its attachments whether encoded, encrypted or otherwise supplied are free from computer viruses, Dorset Council accepts no liability in respect of any loss, cost, damage or expense suffered as a result of accessing this message or any of its attachments. For information on how Dorset Council processes your information, please see www.dorsetcouncil.gov.uk/416433

Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

This e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. It may contain unclassified but sensitive or protectively marked material and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All traffic may be subject to recording and/or monitoring in accordance with relevant legislation. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Dorset Council. Dorset Council does not accept service of documents by fax or other electronic means. Virus checking: Whilst all reasonable steps have been taken to ensure that this electronic communication and its attachments whether encoded, encrypted or otherwise supplied are free from computer viruses, Dorset Council accepts no liability in respect of any loss, cost, damage or expense suffered as a result of accessing this message or any of its attachments. For information on how Dorset Council processes your information, please see www.dorsetcouncil.gov.uk/416433

6

Hi,

I think I worked out my problem last night and it does seem to be our configuration. Our load balancer is configured to split requests based on the domain name but doesn’t appear to be configured to ignore the port number (:443) so instead of matching domain.com and domain.com:443 to domain.com it decides that domain.com:443 is not the same URL and forwards the request somewhere else.

I’ve written this just incase anyone else has a similar issue although I’m sure you wouldn’t.

I did try the proxy base URL the other day but the port number still seemed to be included no matter what I put in; is there a simple way to prevent it including the port number in the get capabilities or is that a fixed part of the OGC spec?

I only ask as most web request applications will default to 443 anyway if the URL starts https://.

Cheers,

Paul

···

Do you want to try turning on WFS strict checkbox? For a while QGIS 2 behaved much better with that setting on :stuck_out_tongue:

–

Jody Garnett

On Thu, 1 Aug 2019 at 00:00, Paul Wittle <paul.wittle@…9945…> wrote:

Hi,

Thanks for getting back to me Jody. After a bit more research I have changed tack on this as the issue is that WFS is not working in QGIS. I’m now investigating whether it might be because the workspace URI are not valid links and QGIS gives up if it gets any 404 responses. Originally these were real links so I’m going to restore that to see if that fixes things but if it does I might put in a patch request on the documentation as I think I saw a message from Andrea on an online thread suggesting the URI should point at a real link if you want to avoid client issues.

Would it not be safer to say that on the documentation as I think it might also have been causing the issues I’m getting when trying to connect via ESRI products as well?

Thanks,

Paul

From: Jody Garnett <jody.garnett@…84…>
Sent: 31 July 2019 06:45
To: Paul Wittle <P.Wittle@…7193…>
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Wrong port number in get capabilities

The proxy base url should be used to adjust the output of the capabilities document: https://docs.geoserver.org/latest/en/user/configuration/globalsettings.html#proxy-base-url

–

Jody Garnett

On Sat, 27 Jul 2019 at 02:35, Paul Wittle <paul.wittle@…9945…> wrote:

Hi,

I’ve just noticed that GeoServer seems to be writing port 443 into our get capabilities statements but this is not the SSL port configured for our Tomcat server.

Is there an easy place to set the port numbers so that GeoServer knows which ports it is using or is it easier to just change the port numbers to use the standard ones?

Thanks,

Paul

This e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. It may contain unclassified but sensitive or protectively marked material and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All traffic may be subject to recording and/or monitoring in accordance with relevant legislation. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Dorset Council. Dorset Council does not accept service of documents by fax or other electronic means. Virus checking: Whilst all reasonable steps have been taken to ensure that this electronic communication and its attachments whether encoded, encrypted or otherwise supplied are free from computer viruses, Dorset Council accepts no liability in respect of any loss, cost, damage or expense suffered as a result of accessing this message or any of its attachments. For information on how Dorset Council processes your information, please see www.dorsetcouncil.gov.uk/416433

Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

This e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. It may contain unclassified but sensitive or protectively marked material and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All traffic may be subject to recording and/or monitoring in accordance with relevant legislation. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Dorset Council. Dorset Council does not accept service of documents by fax or other electronic means. Virus checking: Whilst all reasonable steps have been taken to ensure that this electronic communication and its attachments whether encoded, encrypted or otherwise supplied are free from computer viruses, Dorset Council accepts no liability in respect of any loss, cost, damage or expense suffered as a result of accessing this message or any of its attachments. For information on how Dorset Council processes your information, please see www.dorsetcouncil.gov.uk/416433

7

It’s not part of the OGC specs, nope… probably just a matter of adding a few ifs in this method, to
avoid adding the port in case it’s the default one for the scheme at hand:

https://github.com/geoserver/geoserver/blob/1a35864fc9381a03d3e4c0c94e96aacd02281bd2/src/ows/src/main/java/org/geoserver/ows/util/ResponseUtils.java#L411

(the base url is used everywhere else to build backlinks)

Cheers
Andrea

···

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.