Skip to content
Snippets Groups Projects
  • Andy Green's avatar
    d5882869
    http: compression methods · d5882869
    Andy Green authored
    Add generic http compression layer eanbled at cmake with LWS_WITH_HTTP_STREAM_COMPRESSION.
    
    This is wholly a feature of the HTTP role (used by h1 and h2 roles) and doesn't exist
    outside that context.
    
    Currently provides 'deflate' and 'br' compression methods for server side only.
    
    'br' requires also -DLWS_WITH_HTTP_BROTLI=1 at cmake and the brotli libraries (available in
    your distro already) and dev package.
    
    Other compression methods can be added nicely using an ops struct.
    
    The built-in file serving stuff will use this is the client says he can handle it, and the
    mimetype of the file either starts with "text/" (html and css etc) or is the mimetype of
    Javascript.
    
    zlib allocates quite a bit while in use, it seems to be around 256KiB per stream.  So this
    is only useful on relatively strong servers with lots of memory.  However for some usecases
    where you are serving a lot of css and js assets, it's a nice help.
    
    The patch performs special treatment for http/1.1 pipelining, since the compression is
    performed on the fly the compressed content-length is not known until the end.  So for h1
    only, chunked transfer-encoding is automatically added so pipelining can continue of the
    connection.
    
    For h2 the chunking is neither supported nor required, so it "just works".
    
    User code can also request to add a compression transform before the reply headers were
    sent using the new api
    
    LWS_VISIBLE int
    lws_http_compression_apply(struct lws *wsi, const char *name,
    			   unsigned char **p, unsigned char *end, char decomp);
    
    ... this allows transparent compression of dynamically generated HTTP.  The requested
    compression (eg, "deflate") is only applied if the client headers indicated it was
    supported, otherwise it's a NOP.
    
    Name may be NULL in which case the first compression method in the internal table at
    stream.c that is mentioned as acceptable by the client will be used.
    
    NOTE: the compression translation, same as h2 support, relies on the user code using
    LWS_WRITE_HTTP and then LWS_WRITE_HTTP_FINAL on the last part written.  The internal
    lws fileserving code already does this.
    d5882869
    History
    http: compression methods
    Andy Green authored
    Add generic http compression layer eanbled at cmake with LWS_WITH_HTTP_STREAM_COMPRESSION.
    
    This is wholly a feature of the HTTP role (used by h1 and h2 roles) and doesn't exist
    outside that context.
    
    Currently provides 'deflate' and 'br' compression methods for server side only.
    
    'br' requires also -DLWS_WITH_HTTP_BROTLI=1 at cmake and the brotli libraries (available in
    your distro already) and dev package.
    
    Other compression methods can be added nicely using an ops struct.
    
    The built-in file serving stuff will use this is the client says he can handle it, and the
    mimetype of the file either starts with "text/" (html and css etc) or is the mimetype of
    Javascript.
    
    zlib allocates quite a bit while in use, it seems to be around 256KiB per stream.  So this
    is only useful on relatively strong servers with lots of memory.  However for some usecases
    where you are serving a lot of css and js assets, it's a nice help.
    
    The patch performs special treatment for http/1.1 pipelining, since the compression is
    performed on the fly the compressed content-length is not known until the end.  So for h1
    only, chunked transfer-encoding is automatically added so pipelining can continue of the
    connection.
    
    For h2 the chunking is neither supported nor required, so it "just works".
    
    User code can also request to add a compression transform before the reply headers were
    sent using the new api
    
    LWS_VISIBLE int
    lws_http_compression_apply(struct lws *wsi, const char *name,
    			   unsigned char **p, unsigned char *end, char decomp);
    
    ... this allows transparent compression of dynamically generated HTTP.  The requested
    compression (eg, "deflate") is only applied if the client headers indicated it was
    supported, otherwise it's a NOP.
    
    Name may be NULL in which case the first compression method in the internal table at
    stream.c that is mentioned as acceptable by the client will be used.
    
    NOTE: the compression translation, same as h2 support, relies on the user code using
    LWS_WRITE_HTTP and then LWS_WRITE_HTTP_FINAL on the last part written.  The internal
    lws fileserving code already does this.