I currently have a geoserver serving some 250m tiff terrain data. When I attempt to do things with a proxy, the new URI returns an object that causes requests to fail. When looking at the Resource function (side note, everything is built into Cesium.js), the uri.toString() call at the end of the method returns just the proxy part of the URL string that was passed in.
Proxy version (shortened): /my/proxy/?url=http://localhost:9999/geoserver/cite/ows?
What is returned from new Uri:
authority: undefined
fragment: undefined
path: “/my/proxy/”
query: undefined
scheme: undefined
toString result: /my/proxy/
The above URL’s were decoded for readability here, but they are passed in as encoded (short example: /my/proxy/http%3A%2F%2Flocalhost%3A9999%2Fgeoserver%2Fcite%2Fows?)
I haven’t been able to figure out by experimentation or looking online how to get a Uri to be created with a proxy that doesn’t strip everything except the proxy out. I suspect it has to do with the Uri regex parsing that is done on the Uri, but I would like to avoid having to modify that and introduce bugs myself. Is the format of the proxy just bad? Or is there something else I’m not aware of that is going on? I’ll be glad to provide additional details if needed.
It would be great to see a few code snippets of how you’re setting up this proxy or making these requests with the CesiumJS API. The only Sandcastle example using an explicit proxy is this one, which no longer works because the EarthEnterprise server is currently down I believe:
Ideally if you can provide a way for us to recreate the exact issue that’ll help us narrow down whether it’s an issue in your app or in the library.
Side note: is there a way to shorten the url that you guys use for sharing? Because it’s really long lol. I wasn’t sure if a bit.ly link is acceptable since it kinda masks the url.
These notes are included in the example, but I will include them here as well.
// Something I noticed while working on this is it prints the full url
// string when you console log the resource object here, but in 1.62, it
// prints the Resource object. If I console log Resource._url, then
// I get “http://databases.poly.edu/login” (just the proxy portion)
// If I do “console.log(proxyResource._url)” on here then it also just
// prints the proxy portion. So it seems like maybe older versions
// of cesium don’t parse the url correctly or don’t construct it back?
// It’s honestly confusing me in terms of pinpointing what exactly
// is going wrong.
I will try to provide any additional information or commentary if needed.
I figured out the cause of my issues. I will copy/paste below what I sent out to my team. Note that this was using GeoServerTerrainProvider. The TLDR; is the URL was not being encoded for tile requests, so you end up with http://localhost:8080/geoserver/cite/wms?SERVICE (missing =WMS) in the url that gets put back together, which made requests fail. Further details are below.
One was the url that was used for the request was not encoded, so you would end up with http://localhost:8080/geoserver/cite/wms?SERVICE=WMS and when this is parsed in cesium, it splits things by =, so when it gets put back together, it ends up with url: http://localhost:8080/geoserver/cite/wms?SERVICE (missing =WMS). When it does the getCapabilities request, the whole url is encoded, so splitting along = wouldn’t impact it. So once I found that out, I called the proxy on the url, but I was doing that before it built the whole url (such as replacing bounding box {west}, {east} stuff with values). Geoserver was constantly throwing errors lol. It wasn’t able to replace those with values properly because { and } were getting encoded as well. I passed along the description.proxy (webapp proxy) into resultat since that’s the only thing accessible after doing the {} substitutions. Once the substitutions were complete, then I just had to encode that entirely built url.