Trino gateway not able to forward images from Trino due to incorrect encoding
Trino gateway doesn't return a valid response for the images hosted behind the /ui endpoint. For example /ui/assets/log.png.
This results in default/black images being rendered when UI is routed via Trino Gateway. The difference in the responses can be seen by running a curl command for example:
# When going to Trino directly
raj-manvar:~$ curl -s -X GET http://localhost:8080/ui/assets/logo.png --output - | base64 |head -1
iVBORw0KGgoAAAANSUhEUgAAASwAAAEsCAYAAAB5fY51AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ
# When going via Trino Gateway
raj-manvar:~$ curl -s -X GET http://localhost:8081/ui/assets/logo.png --output - | base64 |head -1
77+9UE5HDQoaCgAAAA1JSERSAAABLAAAASwIBgAAAHl977+9dQAAABl0RVh0U29mdHdhcmUAQWRv
These are what the results look like from the browser: When hitting the /ui/assets/log.png to Trino directly.
When doing the same via Gateway, response is like:
The first 8 bytes of Hexdump value of the response from going to Trino directly matches the PNG specification https://en.wikipedia.org/wiki/PNG 89 50 4e 47 0d 0a 1a 0a as show below:
raj-manvar:~$ curl -s -X GET http://localhost:8080/ui/assets/logo.png --output - | hexdump | head -1
0000000 5089 474e 0a0d 0a1a 0000 0d00 4849 5244
Based on https://stackoverflow.com/questions/6543548/whats-going-on-with-this-byte-array, when the StreamReader doesn't recognize the utf-8 encoding it's replaceed with EF BF BD which matches the response from Gateway
raj-manvar:~$ curl -s -X GET http://localhost:8081/ui/assets/logo.png --output - | hexdump | head -1
0000000 bfef 50bd 474e 0a0d 0a1a 0000 0d00 4849
Gateway primarily deals with the JSON responses coming back from trino and expects the response in a UTF-8 format which then gets converted to an intermediate String object, this could cause an issue with the png content type.
Yea I don't think supporting image is on the roadmap
Thanks for the response. I can describe our usecase for image incase helpful. Currently we have two Trino clusters with hostnames like trino-interactive.xxx and trino-batch.xxx. In our first release of Trino gateway we want to route requests to both clusters via Gateway using routing rules like:
---
name: "interactive"
description: "rules to route request to interactive clusters group"
condition: request.getHeader("Host").contains("interactive")' || 'request.getHeader("X-Trino-Routing-Group") == "interactive"
actions:
- 'result.put("routingGroup", "interactive")'
---
name: "batch"
description: "rules to route request to interactive clusters group"
condition: request.getHeader("Host").contains("batch")' || 'request.getHeader("X-Trino-Routing-Group") == "batch"
actions:
- 'result.put("routingGroup", "batch")'
We tested that above works fine for JDBC and via other Trino supported clients, but it doesn't give a seamless experience for the UI as all images in UI don't work. Our intent is to have 0 user actions for both programmatic and UI access.
Apart from the logo, there are other smaller images like the one used to copy a query text to clipboard that doesn't show up as well.
For example comparing the Query section of the /ui/query.html?$QueryId page, we see:
When using Trino Gateway:
When using Trino directly:
These seem to be using https://www.glyphicons.com/sets/halflings/ which aren't passed successfully via Gateway as well.
I see. In that case I'd suggest you to open a PR to add image support as this is a pretty unique usecase
Oh okay. Do you know if there is any plan to add more info regarding Query statistics/ stages etc in the Gateway UI ? Our main intent for routing via Gateway is because Gateway UI doesn't have all information that Trino UI provides.
I don't think we'll want to support that because we can already see that in Trino's UI. What kind of statistics are you looking for?
Sorry for the late response. Was thinking Gateway UI would be one stop for all UI related aspects, like the Stage view, Resource Utilization summary, Splits etc, but that maybe too ambitious.
Is the long term plan that User will first go to Gateway UI to first find the Trino cluster the query was routed to and then click there to go to Trino UI ?
one (small) downside of that approach is that Trino Gateway doesn't support some auth mechanism like Kerberos because of which the username field maybe empty so users can't always filter to get their submitted query in the history page.
I'm not able to reproduce this with Trino 454 behind Trino Gateway 13. logo.png downloaded directly from Trino or through Trino Gateway via curl or a browser has the same BLAKE2 hash (b2sum):
fa65e6614a5ebdb9d2c3071dccac416a085cf7a6117728650120df294f0c98231844ba8ba7332e5b99a1855c3e100d76086ddbf289f22ffc02a73d654438b9de
Just my two cents, I'm not sure if it's due to some differences in configuration
I re-ran Trino v470 and Gateway 13 both locally, with the default configs but seeing different values of b2sum
raj-manvar:~$ curl -s -X GET http://localhost:8080/ui/assets/logo.png --output - | b2sum
fa65e6614a5ebdb9d2c3071dccac416a085cf7a6117728650120df294f0c98231844ba8ba7332e5b99a1855c3e100d76086ddbf289f22ffc02a73d654438b9de -
raj-manvar:~$ curl -s -X GET http://localhost:8081/ui/assets/logo.png --output - | b2sum
efaf16c57a63dd9171c837e8f8b4d2da9a6b12148eeb95fb712cbfd4adc48563fc8844bb4a3a35d597f9acab483dad67e706bd2bfce1ae64146a26b3ae6f1ecb -
I confirm that upgrading trino-gateway 13 -> 16 broke images, and it seems to be a regression introduced in trino-gateway 14 (https://github.com/trinodb/trino-gateway/commit/40337f6444362478beba6d555c1425f3490b3cc1). Yes, apparently ProxyResponseHandler treats all responses as UTF-8 encoded strings.