@Tim D @Greg OLone : Thanks. I've dome some testing, and it looks like the "Accept-Encoding" header (when set to "identity") is ignored. I think that every response from a Xojo Web app - whether it's for a request handled normally or via HandleURL - is compressed. I can report that as a bug or feature request if you'd like. (My work-around is to decompress the content before relaying it.)
I just looked in the code for App.HandleURL and App.HandleSpecialURL and they will only compress the response if the Accept-Encoding header is set to gzip. I know that this wasn't always the case, but it has been this way since 2015r3.
@Tim D Another interesting thing that I've found - and this isn't a big deal, but I thought it was worth mentioning as it might help someone else at some point - is that Xojo adds a "Content-Length" header to every response, even if that header value has already been set. It doesn't replace the original value. Instead, it ends up setting multiple "Content-Length" headers. Safari ignores the duplicate header, but Chrome can't handle it and it throws an "ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_LENGTH" exception. I admit that it's unusual to set that header value yourself - and that you'd rarely even want to do so. I only ran into it because I'm also relaying headers.
Just to be clear, a xojo web app contains a web server and not a web proxy, as it appears you are trying to create. Since you are just relaying data from another server, you should consider writing your own app using a ServerSocket and TCPSockets. It will be far more efficient and have much less overhead that way.