Disabling Response Compression

In the release notes for 2015r3, it’s mentioned that in the Web framework, a bug was fixed “which prevented gzip compression from being applied to http responses.”

Is there any way to prevent responses from being compressed (either at the app level or on a per-request basis)?

Thanks,

Tim

[quote=307172:@Tim Dietrich]In the release notes for 2015r3, it’s mentioned that in the Web framework, a bug was fixed “which prevented gzip compression from being applied to http responses.”

Is there any way to prevent responses from being compressed (either at the app level or on a per-request basis)?

Thanks,

Tim[/quote]
Yes. Use a browser that doesn’t support gzip.

Why would you want to do this?

@Greg O’Lone: Thanks for the quick response.

The Web app that I’m working on is relaying content from another server, which has already compressed the content. As a result, the content that ultimately gets sent to the user has been double-encoded.

Another question: Does Xojo look at the Accept-Encoding header to determine if it should compress the content? If so, can I override that? (I’m guessing that it’s a read-only header.)

Thanks again.

  • Tim

When you request data from from the “other Server” you can set the Q-value to 0 (https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3) to get the data uncompressed…

Marius: I had already tried using “Accept-Encoding” headers with values of “identity” and “identity;q=0.” However, some of the Web apps that I’m relaying from are Xojo-based, and it appears that they always gzip the content, regardless of the Accept-Encoding header that is passed by the client. I’m not sure if it’s a bug or not.

In the meantime, my work-around is to unzip the content before sending it back.

  • Tim

Yes. Removing that header should turn off compression.

@Greg O’Lone : 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.)

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.

Anyway, thanks again for your help. If you’d like me to file a bug report or feature request regarding the compression, let me know.

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.[quote=307342:@Tim Dietrich]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.[/quote]
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.

I feel the need to resurrect this thread. I am returning dynamically generated images through the handleURL system and these should NOT be gzipped as it actually just adds CPU overhead for no reason. I need to be able to tell the response NOT to gzip the data in this case as it’s slowing down both the server and browser unnecessarily. I just noticed that the browser is saying that my images are gzip encoded, which is just silly.

So sending an image, or already compressed data are the situations where you wouldn’t want this.

Was there ever a feature request made for this that I can sign on to? I would actually call it a bug that you can’t set it and not a “feature” Only text based mime types should ever be gzipped i think. HTML and JSON or plain text. Nothing else.

One thing you could do is create a WebPicture and return a 302 response to have it request the picture instead. You can set the UseCompression flag to False there.

Setting the “Accept-Encoding” header does not work.

[quote=414415:@Daniel Wilson]Setting the “Accept-Encoding” header does not work.
[/quote]
As I’ve mentioned before… the Xojo web http server only supports http/1.0 at this point. Passing “Identity” for accept-encoding is not supported nor is Transfer-Encoding: Chunked for that matter.

Right, thanks for the clarification. So there is no way to stop the encoding? I also tried setting the header to “”.

The framework should be obeying the Accept-Encoding header in that if it doesn’t include gzip, the response shouldn’t be compressed. If it’s not doing that, it’s probably a bug.