Why is CesiumJS molesting my tileset url?

Hi folks,

We are serving a tileset whose URL is this:


And we’re trying to use this tileset in a CesiumJS client program, using a Cesium3DTileset.
So we give the desired url string to the constructor:

  tileset = new Cesium.Cesium3DTileset({ 
    url : 'https://myserver/mytileset.json?somename=some_value_with_a_comma,and_an_encoded_comma%2C', 

But that’s not the request that is sent over the network. Instead, what is sent is:


This has thrown us into complete turmoil :slight_smile:


(1) Can we express the desired URL at all?
It seems to be impossible, using a Cesium3DTileset,
and so we are actually changing/redesigning our tileset server to work around this.
Specifically, it seems that the actual url can’t contain any ‘,’ characters,
since those just simply can’t be expressed at all. (Is that right?)
The amount of design work and discussions we are having right now
in order to figure out what contortions to use to avoid the ‘,’
(and maybe other characters? we don’t even know) is mind-boggling.

(2) Why on earth is CesiumJS doing anything to the ‘url’ at all?
Is there any reason it shouldn’t be simply sending the url string
I give it, as the actual request URL string?

(3) What other restrictions / transformations is it doing?
We know it percent-encodes ‘,’ (in only some positions in the url? not sure),
and ‘%’ apparently gets left alone in the above example;
but in other cases, ‘%’ seems to make it silently fail
(no requests are sent at all), e.g. each of the following examples:

Don Hatch

You need to decode url at server end to get actual url like:

  • Regards

Hi Jacky, thanks for your reply.

I’m afraid I’m not following your answer at all :frowning:

As I said, the url to the tileset is exactly “https://myserver/mytileset.json?somename=some_value_with_a_comma,and_an_encoded_comma%2C” ,
but I can’t figure out how to get cesiumjs to send that as the https request.
Are you saying that’s not a legitimate URL for a 3dtileset?

Note that the algorithm that the server uses to parse that url is an implementation detail (not exposed and not nailed down) and doesn’t necessarily use decodeURIComponent(); in fact, there probably isn’t a function called decodeURIComponent() in the C++ server framework we’re using.


What service has a comma in their URL path? That’s violating several best-practices on good URLs. Now, they’re not evil (as in, they are not considered invalid), but you won’t have any guarantees that a comma is preserved through the whole pipeline.

In other words, it might not be Cesium that can’t deal with it, it can be the URL handling code, JS/TS, maybe if you’re using a framework, and equally on your side as the server side. I find it very odd to have commas in the service, it’s a recipe for disaster as you can’t guarantee it. Is there some other way? Maybe use some other character?

If not, if this is maintained by the service provider, maybe have a word with them? See if they can use other characters to denote what the comma denotes?



The comma , is a reserved character. They usually have to be encoded when the URLs are passed around between applications. It’s sometimes difficult to get this right, though.

I had a short look at the relevant CesiumJS code. It basically extracts the query parameters, resulting in some_value_with_a_comma,and_an_encoded_comma, (note that the originally encoded comma is now decoded!). This is later used to build the actual URL that is sent out - including the query parameters. But this time, they are properly encoded, resulting in the some_value_with_a_comma%2Cand_an_encoded_comma%2C that you see.

So far for the reason. Finding a solution might be more tricky. I’m even a bit on the fence whether this might not be considered as a “bug”: Strictly speaking, the % in
should be encoded as %25, so that this part would become
Decoding this would yield the original URL.