Disabling Response Compression

  1. 2 years ago

    Tim D

    3 Jan 2017 Pre-Release Testers, Xojo Pro, XDC Speakers Richmond, VA

    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

  2. @Tim D 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

    Yes. Use a browser that doesn't support gzip.

    Why would you want to do this?

  3. Tim D

    3 Jan 2017 Pre-Release Testers, Xojo Pro, XDC Speakers Richmond, VA

    @Greg OLone: 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

  4. Marius D

    3 Jan 2017 Pre-Release Testers Herford, Germany

    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...

  5. Tim D

    3 Jan 2017 Pre-Release Testers, Xojo Pro, XDC Speakers Richmond, VA

    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

  6. @Tim D 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.)

    Yes. Removing that header should turn off compression.

  7. Tim D

    4 Jan 2017 Pre-Release Testers, Xojo Pro, XDC Speakers Richmond, VA

    @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.)

    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.

  8. @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.

  9. James S

    21 Apr 2017 Pre-Release Testers, Xojo Pro
    Edited 2 years ago

    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.

  10. Greg O

    21 Apr 2017 Xojo Inc

    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.

  11. 4 weeks ago

    Daniel W

    Nov 14 Australia

    Setting the "Accept-Encoding" header does not work.
    -image-

  12. Greg O

    Nov 15 Xojo Inc

    @Daniel W Setting the "Accept-Encoding" header does not work.
    -image-

    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.

  13. Daniel W

    Nov 15 Australia

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

  14. Greg O

    Nov 16 Xojo Inc

    @Daniel W 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.

or Sign Up to reply!