Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

automatically gzip compress content #654

Closed
clarkevans opened this issue Dec 23, 2020 · 3 comments
Closed

automatically gzip compress content #654

clarkevans opened this issue Dec 23, 2020 · 3 comments

Comments

@clarkevans
Copy link
Contributor

clarkevans commented Dec 23, 2020 •
edited
Loading

It'd be useful to automatically, by default, compress content for HTTP.Response ; this ticket is the opposite of #256 and complementary to #653 -- gzipping content could be done as part of the rendering process as the send buffer is filled (avoiding a literal copy of the user data). As the content is printed to an IO stream, it can be gzipped, and once the buffer is full, a chunked response could be sent for streams that exceed the buffer length.

One of the challenges here is having a bypass for static content that is already compressed; for example, many resource bundles precompress their output so that you don't have to do it at runtime.

In a WSGI like stack, this is implemented as a Response proxy. Basically, it's a wrapper that, when you print the headers looks to see if Transfer-Encoding is already set, if so, it is a no-op. A FileResponse object would notice that the file being served may have a gzip extension and start with the gzip chararaters and set the headers appropriately. The GzipResponse would then use the body of the wrapped response, reading or printing it, and gzipping the results. There are some advantages of being a proxy, but, it's not a necessary requirement for the design it could be built-in as a flag of some sort.
@fonsp
Copy link
Member

fonsp commented Apr 17, 2021 •
edited
Loading

Awesome! And it should check for gzip in the Accept-Encoding header of the request -- the request can be retrieved from a Response.

@fredrikekre
Copy link
Member

#256

@jvo203
Copy link

jvo203 commented Apr 9, 2024 •
edited
Loading

Are you sure this issue has been solved fully and can be closed? The HTTP streams do not seem to be gzip-compressed automatically:

function streamXEvents(http::HTTP.Streams.Stream)
      # ...
      HTTP.setstatus(http, 200)
      startwrite(http)
      write(http, "<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n<meta charset=\"utf-8\">\n")
      write(
        http,
        "<link href=\"https://fonts.googleapis.com/css?family=Inconsolata\" rel=\"stylesheet\"/>\n",
     )
      # ...
     write(http, "</body></html>")
    return nothing
end

The HTTP request does contain Accept-Encoding | gzip, deflate, br and yet the response is not being compressed at all, all it contains is

HTTP/1.1 200 OK
Transfer-Encoding: chunked

with the body size being the uncompressed original. So the streaming HTTP response is not being compressed on the fly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@clarkevans @fonsp @fredrikekre @jvo203