[Geoserver-users] forwarding GEBCO WMS fails - help needed

Hi,

I’m looking to install geoserver on a ship.

I’d like to use the GEBCO WMS service to provide a background map layer, but cache it locally to avoid internet traffic.

The capabilities doc is at:
https://wms.gebco.net/mapserv?REQUEST=GETCAPABILITIES&VERSION=1.3.0&SERVICE=WMS

The layer I wish to provide is: GEBCO_LATEST_SUB_ICE_TOPO

I can connect & get the capabilities doc in a browser. I can select & open the layer in QGIS.

When I try to set up a WMS store in Geoserver I enter the required parameters, but get told the connection test to the URL failed with error 403.

I understand this means the Gebco server is refusing to reply with the doc. I’m not sure why the URL works from a browser but fails when sent from Geoserver, any suggestions appreciated, as far as I know it is an identical request, from the same host.

Thanks,

Brent Wood.

Pheraps a matter of user agent? The service might have a white list of acceptable ones (eh well known client apps).

Just an idea…

Andrea

Il dom 21 apr 2024, 00:44 Brent Wood via Geoserver-users <geoserver-users@lists.sourceforge.net> ha scritto:

Hi,

I’m looking to install geoserver on a ship.

I’d like to use the GEBCO WMS service to provide a background map layer, but cache it locally to avoid internet traffic.

The capabilities doc is at:
https://wms.gebco.net/mapserv?REQUEST=GETCAPABILITIES&VERSION=1.3.0&SERVICE=WMS

The layer I wish to provide is: GEBCO_LATEST_SUB_ICE_TOPO

I can connect & get the capabilities doc in a browser. I can select & open the layer in QGIS.

When I try to set up a WMS store in Geoserver I enter the required parameters, but get told the connection test to the URL failed with error 403.

I understand this means the Gebco server is refusing to reply with the doc. I’m not sure why the URL works from a browser but fails when sent from Geoserver, any suggestions appreciated, as far as I know it is an identical request, from the same host.

Thanks,

Brent Wood.


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

Maybe try again, it works for me from GeoServer v2.25.0:

image.png

···

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

With access to Brent’s GeoServer, I have managed to reproduce this problem, and it appears to be a combination of GeoTools HTTPClient (not MultithreadedHttpClient) and the GEBCO MapServer not allowing HTTP Header “accept”: “text/html, image/gif, image/jpeg, *; q=.2, /; q=.2” for some reason.

To reproduce:

In Postman, GET https://wms.gebco.net/mapserv?REQUEST=GETCAPABILITIES&VERSION=1.3.0&SERVICE=WMS works fine, until the Accept header is changed from the default / to text/html, image/gif, image/jpeg, *; q=.2, /; q=.2
Returns 403 Unauthorised

This Accept header appears to only be sent by GeoTools HTTPClient and is not sent by the GeoTools MultithreadedHttpClient, which is what I had on by default, when the cascaded WMS worked for me on my GeoServer (previous email):

image.png

(in GeoServer New WMS Connection)

Is this a GeoTools bug? Or GeoServer?

And then under what circumstances would the WMS data store fall back to the Simple HTTPClient rather than using the MultithreadedHttpClient (HTTP connection pooling), even if the above is ticked?

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

image.png

···

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

It sounds like we (GeoTools) should accept text/xml especially when requesting getCapabilities documents. But I’m really not sure 403 is the correct response to not accepting the right content type.

Ian

image.png

image.png

···

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

Ian Turton

Is there a (simple) way to set Geoserver up to use the MultithreadedHttpClient as default instead of HTTPClient?

That would seem to fix the issue for me, before any bug fixes are implemented.

Thanks,

Brent

It sounds like we (GeoTools) should accept text/xml especially when requesting getCapabilities documents. But I’m really not sure 403 is the correct response to not accepting the right content type.

Ian

On Mon, 22 Apr 2024 at 14:03, Peter Smythe <gs@anonymised.com> wrote:

With access to Brent’s GeoServer, I have managed to reproduce this problem, and it appears to be a combination of GeoTools HTTPClient (not MultithreadedHttpClient) and the GEBCO MapServer not allowing HTTP Header “accept”: “text/html, image/gif, image/jpeg, *; q=.2, /; q=.2” for some reason.

To reproduce:

In Postman, GET https://wms.gebco.net/mapserv?REQUEST=GETCAPABILITIES&VERSION=1.3.0&SERVICE=WMS works fine, until the Accept header is changed from the default / to text/html, image/gif, image/jpeg, *; q=.2, /; q=.2
Returns 403 Unauthorised

This Accept header appears to only be sent by GeoTools HTTPClient and is not sent by the GeoTools MultithreadedHttpClient, which is what I had on by default, when the cascaded WMS worked for me on my GeoServer (previous email):

image.png

(in GeoServer New WMS Connection)

Is this a GeoTools bug? Or GeoServer?

And then under what circumstances would the WMS data store fall back to the Simple HTTPClient rather than using the MultithreadedHttpClient (HTTP connection pooling), even if the above is ticked?

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

On Sun, 21 Apr 2024 at 15:19, Peter Smythe <gs@anonymised.com.> wrote:

Maybe try again, it works for me from GeoServer v2.25.0:

image.png

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

On Sun, 21 Apr 2024 at 00:50, Brent Wood via Geoserver-users <geoserver-users@lists.sourceforge.net> wrote:

Hi,

I’m looking to install geoserver on a ship.

I’d like to use the GEBCO WMS service to provide a background map layer, but cache it locally to avoid internet traffic.

The capabilities doc is at:
https://wms.gebco.net/mapserv?REQUEST=GETCAPABILITIES&VERSION=1.3.0&SERVICE=WMS

The layer I wish to provide is: GEBCO_LATEST_SUB_ICE_TOPO

I can connect & get the capabilities doc in a browser. I can select & open the layer in QGIS.

When I try to set up a WMS store in Geoserver I enter the required parameters, but get told the connection test to the URL failed with error 403.

I understand this means the Gebco server is refusing to reply with the doc. I’m not sure why the URL works from a browser but fails when sent from Geoserver, any suggestions appreciated, as far as I know it is an identical request, from the same host.

Thanks,

Brent Wood.


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


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

Ian Turton

  1. apr. 2024 kl. 15:01 skrev Peter Smythe <gs@anonymised.com>:

And then under what circumstances would the WMS data store fall back to the Simple HTTPClient rather than using the MultithreadedHttpClient (HTTP connection pooling), even if the above is ticked?

Hi,
The answer to the question about how WMS data store would fall back to Simple HTTPClient if the “Use HTTP connection pooling” checkbox is ticked, is that it shouldn’t happen. It might happen something if the server is missing the gt-http-commons.jar, but I assume that would lead to an exception.

What I’m confused about is how the two classes should influence on what is sent as Accept-header. Nothing in the code indicates something like that.

Best regards,

Roar Brænden

On Wed, Apr 24, 2024 at 3:30 PM Roar Brænden <roar.brenden.no@anonymised.com> wrote:

What I’m confused about is how the two classes should influence on what is sent as Accept-header. Nothing in the code indicates something like that.

One is the built-in java client, the other the Apache one… I guess they might have different defaults, if no accept-header is specified?
Just thinking out loud

Cheers
Andrea

Hi Brent

Like the others say, this problem should not be happening, and it is the first time that I am encountering it. Perhaps it has something to do with the way that you installed it. Could you provide those details (OS, Java version, application server, bin/war/docker, any extensions installed, etc.) - best would be opening an issue on https://osgeo-org.atlassian.net/jira/software/c/projects/GEOS/boards/8 so that we can track this - and perhaps you would like to install GeoServer in a different way (or maybe on a different server) to see if you can reproduce the problem? I can recommend https://github.com/geoserver/docker as a proven working solution for you to continue with.

image.png

image.png

···

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

Yeah anyway, AKWangChas the me, what’s the this oranges? and that’s my(the) sign

d1grfy39ztai4o.cloudfront.net/sites/default/files/images/membership/benefits/acp-email-sig-master-rgb.png

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4WvVpxjs39JiWs0DlQpEDVPkVE8zWQ_yXGWqg_yEb6vXZ24BowbRPs17KvXc9aKbwA2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4R628Y5kGJdc_10NW9GpxbnhgdGNZ5xMbT1jQXXNPJtTfWjtvy3ThXWoYVLCI27w4w2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4cCq_IplesTWlVAxoy-Qwa-HNYukWA6f5lglWxqhjzsLN40nJWtXRp7PtdrYsRjrJA2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4VkVFopYiUkfc_mv8OKLoAoR909AjIzeIUx9625jzV_yoXv6146rjwe1lJJVLk5wLw2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4R84IGhhWCaLLvo-yKkiNIzGZKZJrKlz1iH2RqD8QWbQLyiBBx7HsvfqPFv1KM9HYw2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4btk7hYWQg1z2kX5nceTBeZl0CLQkuqczRh2CGMVyUH-4i4SvXVCXqKsa-Sqund4EA2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4bKB9i5JcPA7K-SjEXcuPVVVrXzaRGTMZefhtJAvGOh_zYa1TCmaxzxu3qmE3tiZUg2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4accNHXz-lYTJ0NRgvdwv3rDVqRv_U1pjJYM7_07_QhiIWx0Zp-n-gfXbi5Y0t6Lfw2

https://membersuite.aala.org.au/Sys/Profile/PhotoGallery/43401/0/226431?memberId=57474101&dh=24&cppr=0

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4XveGEGMqpC9PNldWuG5ANmeZvBlYhDALnTvm6iu4LT-ulT1E8T_YB2KqDhbT4JycA2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4SzN0476R5hPkVEPdTqOAxxFFbFR4EgPlN7QOlUJPjATmSA-zBgdW12y7WlxWjYZ8w2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4UDQ-nLw95DqsZJ7pTPY6Aq0i-7l-_Su8wILhkl6AgsfQLe5fdN8OQsPzD4bPp9EWQ2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4bXgChfdh9AR9OAygHxsGgXdxfZCPNqwdaL_9of_lRbiPcTwkJMRd4ZG-CCW7Ewh4Q2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4amezH8y5IVXnoHqq2yY0mfBMRVjI6PXuWJyGoPinVNxhy_JWn2aLpz1HmrHwA3EeQ2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4dwBgTDB2jyXS_kePhssCzESNnQRrQh_sjZzo2sVjCwAg5zg-ZiqKieioz_Uog545Q2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4dwBgTDB2jyXS_kePhssCzESNnQRrQh_sjZzo2sVjCwAg5zg-ZiqKieioz_Uog545Q2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4SqvOZfWLrRfNy_78c_wIcXrn5ZuRQpiM2nx_mNeBfUcYciShWD06cT2fO6wCY_MkA2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4SqvOZfWLrRfNy_78c_wIcXrn5ZuRQpiM2nx_mNeBfUcYciShWD06cT2fO6wCY_MkA2

https:royalairforcesassociation.my.site.comcommunitysmy-details ID:00597651

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4eNGxo-iDlx56HJskPvqiCgSwf09BXS9R6u9s_iz4HlVFpFNCS2VqbU4CKumISoOHA2

在 2024年4月24日 星期三 下午10:11:28 [GMT+8], Peter Smythegs@anonymised.com 寫道:

Hi Brent

Like the others say, this problem should not be happening, and it is the first time that I am encountering it. Perhaps it has something to do with the way that you installed it. Could you provide those details (OS, Java version, application server, bin/war/docker, any extensions installed, etc.) - best would be opening an issue on https://osgeo-org.atlassian.net/jira/software/c/projects/GEOS/boards/8 so that we can track this - and perhaps you would like to install GeoServer in a different way (or maybe on a different server) to see if you can reproduce the problem? I can recommend https://github.com/geoserver/docker as a proven working solution for you to continue with.

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

On Wed, 24 Apr 2024 at 14:33, Brent Wood <pcreso@anonymised.com> wrote:

Is there a (simple) way to set Geoserver up to use the MultithreadedHttpClient as default instead of HTTPClient?

That would seem to fix the issue for me, before any bug fixes are implemented.

Thanks,

Brent

It sounds like we (GeoTools) should accept text/xml especially when requesting getCapabilities documents. But I’m really not sure 403 is the correct response to not accepting the right content type.

Ian

On Mon, 22 Apr 2024 at 14:03, Peter Smythe <gs@anonymised.com839…> wrote:

With access to Brent’s GeoServer, I have managed to reproduce this problem, and it appears to be a combination of GeoTools HTTPClient (not MultithreadedHttpClient) and the GEBCO MapServer not allowing HTTP Header “accept”: “text/html, image/gif, image/jpeg, *; q=.2, /; q=.2” for some reason.

To reproduce:

In Postman, GET https://wms.gebco.net/mapserv?REQUEST=GETCAPABILITIES&VERSION=1.3.0&SERVICE=WMS works fine, until the Accept header is changed from the default / to text/html, image/gif, image/jpeg, *; q=.2, /; q=.2
Returns 403 Unauthorised

This Accept header appears to only be sent by GeoTools HTTPClient and is not sent by the GeoTools MultithreadedHttpClient, which is what I had on by default, when the cascaded WMS worked for me on my GeoServer (previous email):

image.png

(in GeoServer New WMS Connection)

Is this a GeoTools bug? Or GeoServer?

And then under what circumstances would the WMS data store fall back to the Simple HTTPClient rather than using the MultithreadedHttpClient (HTTP connection pooling), even if the above is ticked?

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

On Sun, 21 Apr 2024 at 15:19, Peter Smythe <gs@anonymised.com> wrote:

Maybe try again, it works for me from GeoServer v2.25.0:

image.png

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

On Sun, 21 Apr 2024 at 00:50, Brent Wood via Geoserver-users <geoserver-users@anonymised.com.sourceforge.net> wrote:

Hi,

I’m looking to install geoserver on a ship.

I’d like to use the GEBCO WMS service to provide a background map layer, but cache it locally to avoid internet traffic.

The capabilities doc is at:
https://wms.gebco.net/mapserv?REQUEST=GETCAPABILITIES&VERSION=1.3.0&SERVICE=WMS

The layer I wish to provide is: GEBCO_LATEST_SUB_ICE_TOPO

I can connect & get the capabilities doc in a browser. I can select & open the layer in QGIS.

When I try to set up a WMS store in Geoserver I enter the required parameters, but get told the connection test to the URL failed with error 403.

I understand this means the Gebco server is refusing to reply with the doc. I’m not sure why the URL works from a browser but fails when sent from Geoserver, any suggestions appreciated, as far as I know it is an identical request, from the same host.

Thanks,

Brent Wood.


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


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

Ian Turton


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

images (55).jpeg

在臺灣沒有退伍令的人的想法是不同的,

它臺灣滿街都是有退伍令的臺灣軍人 我這樣歐洲防務局EDA的超級賽亞人的身份 看來跟它們一起 這樣才安全 知道嗎?

d1grfy39ztai4o.cloudfront.net/sites/default/files/images/membership/benefits/acp-email-sig-master-rgb.png

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4WvVpxjs39JiWs0DlQpEDVPkVE8zWQ_yXGWqg_yEb6vXZ24BowbRPs17KvXc9aKbwA2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4R628Y5kGJdc_10NW9GpxbnhgdGNZ5xMbT1jQXXNPJtTfWjtvy3ThXWoYVLCI27w4w2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4cCq_IplesTWlVAxoy-Qwa-HNYukWA6f5lglWxqhjzsLN40nJWtXRp7PtdrYsRjrJA2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4VkVFopYiUkfc_mv8OKLoAoR909AjIzeIUx9625jzV_yoXv6146rjwe1lJJVLk5wLw2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4R84IGhhWCaLLvo-yKkiNIzGZKZJrKlz1iH2RqD8QWbQLyiBBx7HsvfqPFv1KM9HYw2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4btk7hYWQg1z2kX5nceTBeZl0CLQkuqczRh2CGMVyUH-4i4SvXVCXqKsa-Sqund4EA2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4bKB9i5JcPA7K-SjEXcuPVVVrXzaRGTMZefhtJAvGOh_zYa1TCmaxzxu3qmE3tiZUg2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4accNHXz-lYTJ0NRgvdwv3rDVqRv_U1pjJYM7_07_QhiIWx0Zp-n-gfXbi5Y0t6Lfw2

https://membersuite.aala.org.au/Sys/Profile/PhotoGallery/43401/0/226431?memberId=57474101&dh=24&cppr=0

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4XveGEGMqpC9PNldWuG5ANmeZvBlYhDALnTvm6iu4LT-ulT1E8T_YB2KqDhbT4JycA2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4SzN0476R5hPkVEPdTqOAxxFFbFR4EgPlN7QOlUJPjATmSA-zBgdW12y7WlxWjYZ8w2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4UDQ-nLw95DqsZJ7pTPY6Aq0i-7l-_Su8wILhkl6AgsfQLe5fdN8OQsPzD4bPp9EWQ2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4bXgChfdh9AR9OAygHxsGgXdxfZCPNqwdaL_9of_lRbiPcTwkJMRd4ZG-CCW7Ewh4Q2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4amezH8y5IVXnoHqq2yY0mfBMRVjI6PXuWJyGoPinVNxhy_JWn2aLpz1HmrHwA3EeQ2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4dwBgTDB2jyXS_kePhssCzESNnQRrQh_sjZzo2sVjCwAg5zg-ZiqKieioz_Uog545Q2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4dwBgTDB2jyXS_kePhssCzESNnQRrQh_sjZzo2sVjCwAg5zg-ZiqKieioz_Uog545Q2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4SqvOZfWLrRfNy_78c_wIcXrn5ZuRQpiM2nx_mNeBfUcYciShWD06cT2fO6wCY_MkA2

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4SqvOZfWLrRfNy_78c_wIcXrn5ZuRQpiM2nx_mNeBfUcYciShWD06cT2fO6wCY_MkA2

https:royalairforcesassociation.my.site.comcommunitysmy-details ID:00597651

https://membersuite.aala.org.au/resources/photo/uTljNHN_T9II2VPclRSi4eNGxo-iDlx56HJskPvqiCgSwf09BXS9R6u9s_iz4HlVFpFNCS2VqbU4CKumISoOHA2

在 2024年4月24日 星期三 下午10:11:28 [GMT+8], Peter Smythegs@anonymised.com 寫道:

Hi Brent

Like the others say, this problem should not be happening, and it is the first time that I am encountering it. Perhaps it has something to do with the way that you installed it. Could you provide those details (OS, Java version, application server, bin/war/docker, any extensions installed, etc.) - best would be opening an issue on https://osgeo-org.atlassian.net/jira/software/c/projects/GEOS/boards/8 so that we can track this - and perhaps you would like to install GeoServer in a different way (or maybe on a different server) to see if you can reproduce the problem? I can recommend https://github.com/geoserver/docker as a proven working solution for you to continue with.

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

On Wed, 24 Apr 2024 at 14:33, Brent Wood <pcreso@anonymised.com> wrote:

Is there a (simple) way to set Geoserver up to use the MultithreadedHttpClient as default instead of HTTPClient?

That would seem to fix the issue for me, before any bug fixes are implemented.

Thanks,

Brent

It sounds like we (GeoTools) should accept text/xml especially when requesting getCapabilities documents. But I’m really not sure 403 is the correct response to not accepting the right content type.

Ian

On Mon, 22 Apr 2024 at 14:03, Peter Smythe <gs@anonymised.com839…> wrote:

With access to Brent’s GeoServer, I have managed to reproduce this problem, and it appears to be a combination of GeoTools HTTPClient (not MultithreadedHttpClient) and the GEBCO MapServer not allowing HTTP Header “accept”: “text/html, image/gif, image/jpeg, *; q=.2, /; q=.2” for some reason.

To reproduce:

In Postman, GET https://wms.gebco.net/mapserv?REQUEST=GETCAPABILITIES&VERSION=1.3.0&SERVICE=WMS works fine, until the Accept header is changed from the default / to text/html, image/gif, image/jpeg, *; q=.2, /; q=.2
Returns 403 Unauthorised

This Accept header appears to only be sent by GeoTools HTTPClient and is not sent by the GeoTools MultithreadedHttpClient, which is what I had on by default, when the cascaded WMS worked for me on my GeoServer (previous email):

image.png

(in GeoServer New WMS Connection)

Is this a GeoTools bug? Or GeoServer?

And then under what circumstances would the WMS data store fall back to the Simple HTTPClient rather than using the MultithreadedHttpClient (HTTP connection pooling), even if the above is ticked?

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

On Sun, 21 Apr 2024 at 15:19, Peter Smythe <gs@anonymised.com> wrote:

Maybe try again, it works for me from GeoServer v2.25.0:

image.png

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe

On Sun, 21 Apr 2024 at 00:50, Brent Wood via Geoserver-users <geoserver-users@anonymised.com.sourceforge.net> wrote:

Hi,

I’m looking to install geoserver on a ship.

I’d like to use the GEBCO WMS service to provide a background map layer, but cache it locally to avoid internet traffic.

The capabilities doc is at:
https://wms.gebco.net/mapserv?REQUEST=GETCAPABILITIES&VERSION=1.3.0&SERVICE=WMS

The layer I wish to provide is: GEBCO_LATEST_SUB_ICE_TOPO

I can connect & get the capabilities doc in a browser. I can select & open the layer in QGIS.

When I try to set up a WMS store in Geoserver I enter the required parameters, but get told the connection test to the URL failed with error 403.

I understand this means the Gebco server is refusing to reply with the doc. I’m not sure why the URL works from a browser but fails when sent from Geoserver, any suggestions appreciated, as far as I know it is an identical request, from the same host.

Thanks,

Brent Wood.


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


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

Ian Turton


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

images - 2024-04-25T174711.370.jpeg

  1. apr. 2024 kl. 15:34 skrev Andrea Aime <andrea.aime@anonymised.com>:

On Wed, Apr 24, 2024 at 3:30 PM Roar Brænden <roar.brenden.no@anonymised.com…> wrote:

What I’m confused about is how the two classes should influence on what is sent as Accept-header. Nothing in the code indicates something like that.

One is the built-in java client, the other the Apache one… I guess they might have different defaults, if no accept-header is specified?
Just thinking out loud

Hi,

You are absolutely right, Andrea, about that Accept-header being default for the Java built-in client.
Here I have provided extended logging of the HTTP traffic for the calls with SimpleHttpClient and MultithreadedHttpClient when they’re used in combination with org.geotools.wms.WebMapServer:

[25.apr. 14:39:08] FINE <org.geotools.http.SimpleHttpClient get> URL is https://wms.gebco.net/mapserv?REQUEST=GetCapabilities&VERSION=1.3.0&SERVICE=WMS
[25.apr. 14:39:08] FINE <org.geotools.http.SimpleHttpClient openConnection> Setting header User-Agent = GeoTools HTTPClient (32-SNAPSHOT)
[25.apr. 14:39:08] FINE <sun.net.www.protocol.http.HttpURLConnection writeRequests> sun.net.www.MessageHeader@anonymised.com7… pairs:
{GET /mapserv?REQUEST=GetCapabilities&VERSION=1.3.0&SERVICE=WMS HTTP/1.1: null}
{User-Agent: GeoTools HTTPClient (32-SNAPSHOT)}
{Host: wms.gebco.net}
{Accept: text/html, image/gif, image/jpeg, *; q=.2, /; q=.2}
{Connection: keep-alive}

[25.apr. 14:51:01] FINE <org.apache.http.headers onRequestSubmitted> http-outgoing-0 >> GET /mapserv?REQUEST=GetCapabilities&VERSION=1.3.0&SERVICE=WMS HTTP/1.1
[25.apr. 14:51:01] FINE <org.apache.http.headers onRequestSubmitted> http-outgoing-0 >> Host: wms.gebco.net
[25.apr. 14:51:01] FINE <org.apache.http.headers onRequestSubmitted> http-outgoing-0 >> Connection: Keep-Alive
[25.apr. 14:51:01] FINE <org.apache.http.headers onRequestSubmitted> http-outgoing-0 >> User-Agent: GeoTools/32-SNAPSHOT (MultithreadedHttpClient)
[25.apr. 14:51:01] FINE <org.apache.http.headers onRequestSubmitted> http-outgoing-0 >> Accept-Encoding: gzip,deflate

Certainly that first Accept header seems a little out-dated, but as Ian mentioned it doesn’t explain why we will get a 403 status code.

Regards Roar

Because the ESRI devs don’t understand how the web works!

Ian

···

Ian Turton