Config option to control tilejson.json response urls

[Frank Purcell]

Is your feature request related to a problem? Please describe.
The tilejson.json response provides URL(s) with hard-coded path information of /otp/routers/default/ that assumes how OTP is hosted. These assumptions are problematic in my environment for two reasons:

1. https://maps.trimet.org/otp_ct/vectorTiles/stops,rentalVehicles,rentalVehicles,rentalStations/tilejson.json returns a URL that doesn't obey my /otp_ct/ proxy. Instead I get http://maps.trimet.org/otp/routers/default/, although /otp/ is not a valid path.
2. Notice that I made a request via https:// above, but I was given back an http:// URL in response, ala http://maps.trimet.org/otp/routers/default/vectorTiles/stops,rentalVehicles,rentalVehicles,rentalStations/{z}/{x}/{y}.pbf. That http:// mis-match breaks browser security, preventing the client from using the endpoint.

Goal / high level use-case
A config variable(s), say "vectorTileResponseURL" in router.json, that allows control over response URL of everything from the https:// up until the start of /vectorTiles/.

Describe the solution you'd like
Use of the config variable "vectorTileResponseURL: https://maps.trimet.org/otp_ct" will allow me to control the response to tilejson.json, to expose URLs that look like this: https://maps.trimet.org/otp_ct/vectorTiles/stops,rentalVehicles,rentalVehicles,rentalStations/{z}/{x}/{y}.pbf.

Describe alternatives you've considered
I'm worried that vectorTileResponseURL might be too narrow, and there are other places where OTP may return a URL with hard-coded url values. So making this config more generic and/or more granular is fine by me. What I do need to control is the http/https, the domain name, and the otp/routers/default paths.

Additional context
Gitter discussion: https://matrix.to/#/!oXNNoHKzbaSOlFzLEt:gitter.im/$JVvCGM-s3Iz5r2wbmlPM7AGTdF8otxM-udibs7wGii8?via=gitter.im&via=matrix.org&via=mozilla.org

[Leonard Ehrenfried]

The http/https you can fix yourself by setting the X-Forwarded-Proto header in your proxy. Have a look at the following method:

OpenTripPlanner/src/main/java/org/opentripplanner/framework/io/HttpUtils.java

Lines 24 to 42 in 71f7393

 public static String getBaseAddress(UriInfo uri, HttpHeaders headers) { 
   String protocol; 
   if (headers.getRequestHeader(HEADER_X_FORWARDED_PROTO) != null) { 
     protocol = headers.getRequestHeader(HEADER_X_FORWARDED_PROTO).getFirst(); 
   } else { 
     protocol = uri.getRequestUri().getScheme(); 
   } 
  
   String host; 
   if (headers.getRequestHeader(HEADER_X_FORWARDED_HOST) != null) { 
     host = headers.getRequestHeader(HEADER_X_FORWARDED_HOST).getFirst(); 
   } else if (headers.getRequestHeader(HEADER_HOST) != null) { 
     host = headers.getRequestHeader(HEADER_HOST).getFirst(); 
   } else { 
     host = uri.getBaseUri().getHost() + ":" + uri.getBaseUri().getPort(); 
   } 
  
   return protocol + "://" + host; 
 } 

If you want to set a desired host name you can use X-Forwarded-Host or just Host.

Now the path part is hard-coded and I will have a think about how to make it configurable. I will speak about this in the dev meeting and will present a solution here, when I have it.

[Leonard Ehrenfried]

My current idea is to change the way the vector tile layers are configured. I think I would add an extra layer to the JSON so it would look like this:

{
  "vectorTiles": {
     "basePath": "/otp_ct/routers/default/",
     "layers": {
         // put layer definition here
      }
  }
}

This would mean that all users of this feature would have to change their config. @miles-grant-ibigroup @optionsome Would you be ok with that?

[Joel Lappalainen]

That is fine.

[miles-grant-ibigroup]

I like it. Clean!

[Frank Purcell]

+1

BTW, I'm assuming that "basePath": "/otp_ct" would be valid, and then the vector tiles would be served via "protocol + "://" + host + basePath + '/vectorTiles/.../tilejson.json' (e.g., 'routers/default' does not need to be in the url).

[Leonard Ehrenfried]

Changing the path that OTP serves the tiles is hard so therefore I suggest the following:

• the config only changes the URLs in tilejson.json. it is the responsibility of the proxy to send the request to the correct path.
• The current mechanism for figuring out the protocol and host remains as it is. (But that we can change if there is the desire. WDYT, @fpurcell ?)
• if you set this config param, the following will be replaced: /otp/routers/default/vectorTiles so in @fpurcell's case the correct value for his config should be /otp_ct/routers/default/vectorTiles. In my view, this gives you the most flexibility to choose the proxying setup that you want.

What do you think about that, @fpurcell ?

[Frank Purcell]

I think we're good, but your bullet 3 is confusing me a bit, Leonard.

For my system, https://maps.trimet.org/otp_ct proxies to something like https://maps.trimet.org:8080/otp/routers/default. The point being, I don't have /otp/routers/default on any url path.

So by using "basePath": "/otp_ct", I'd expect to see tilejson.json return [https://maps.trimet.org/otp_ct/vectorTiles/stops,rentalVehicles,rentalVehicles,rentalStations/{z}/{x}/{y}.pbf]

And from there, urls to the vector tiles get served up, ala: https://maps.trimet.org/otp_ct/vectorTiles/stops,rentalVehicles,rentalVehicles,rentalStations/15/5217/11719.pbf (e.g., this is a valid url on my system to one of the vector tiles siting behind the /otp_ct proxy).

[Frank Purcell]

BTW, I wouldn't be opposed to "basePath": "/otp_ct/vectorTiles", as that completes the static part of the https://maps.trimet.org/otp_ct/vectorTiles/stops,rentalVehicles,rentalVehicles,rentalStations/{z}/{x}/{y}.pbf url that I'm expecting to be returned by the call to https://maps.trimet.org/otp_ct/vectorTiles/stops,rentalVehicles,rentalVehicles,rentalStations/tilejson.json

[Leonard Ehrenfried]

Yes, that's what I'm suggesting: your config value would be /otp_ct/vectorTiles. Is that ok?

[Frank Purcell]

Yup, works for me.

[Leonard Ehrenfried]

Feature preview

Before

With basePath set to /otp_ct/vectorTiles