Bug 52860 - Support Transfer-Encoding: gzip
Summary: Support Transfer-Encoding: gzip
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_deflate (show other bugs)
Version: 2.5-HEAD
Hardware: All All
: P2 enhancement with 6 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: PatchAvailable
Depends on:
Reported: 2012-03-08 21:13 UTC by Tim B
Modified: 2016-03-09 02:37 UTC (History)
3 users (show)

patch against trunk r1298556 (14.73 KB, text/plain)
2012-03-08 21:13 UTC, Tim B
patch against trunk r1376741 (15.48 KB, patch)
2012-08-23 22:45 UTC, Tim B
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim B 2012-03-08 21:13:53 UTC
Created attachment 28443 [details]
patch against trunk r1298556

In a comment to Bug 39797, Roy Fielding calls for Apache httpd to implement transfer-encoding.

I'm filing this bug to ask for that improvement. It's against mod_deflate because that seems like the best place, but Roy Fielding actually suggested a separate HTTP filter module.

I want to see at least one HTTP server that can talk gzip transfer-encoding. I looked long and hard at most of the open source webservers, but only Apache httpd had enough flexibility to make adding this feature feasible.

I'm attaching some code. This isn't the sort of patch you commit, but it illustrates the kind of behaviour I'm describing. The patch adds a new filter type GZIPTE which needs to run after the content is set but before chunked transfer-encoding is applied. I've tested this using recent cURL as a client and it behaves at the HTTP level just the way I would expect.

I'd very much welcome help from more experienced developers in making this into a patch submission that belongs in trunk, with appropriate tests, documentation and error codes. This is my first C language contribution to a public project so please bear that in mind.

NB: if using cURL, remember to add the "TE: gzip" request header manually. There's no command line shortcut for this yet.
Comment 2 Tim B 2012-08-23 22:45:44 UTC
Created attachment 29270 [details]
patch against trunk r1376741

The only real update is to add a call to have_ssl_compression() in the right place.
Comment 3 Eric Covener 2013-07-09 14:58:31 UTC
Any anecdotal info about client support? Or is it a chicken/egg problem?
Comment 4 Tim B 2013-07-09 15:07:29 UTC
It's a chicken-and-egg issue. Few mainstream browsers support gzip transfer-encoding.

Opera used to support gzip TE, but I'm not sure they're keeping it.

libcurl supports compressed transfer encodings since 2011: http://curl.haxx.se/changes.html#7_21_6

…however, there's no webserver that will serve this. Once it's available in httpd it should be safe to enable it by default (legacy clients don't request gzip TE). Famous last words?
Comment 5 Jesús Cea 2013-08-31 01:12:57 UTC
I just hit this. I was trying to use "Range" with "Content-encoding: gzip", and that is not working as expected. Investigating what could I do, I got this in my Python code:

    # Interferencia con 'range'
    # http://forum.nginx.org/read.php?2,209738,210053
    del s.headers["Accept-Encoding"]
    # Esto no hace nada en las versiones actuales de Apache,
    # pero sí funcionará en las futuras:
    # https://issues.apache.org/bugzilla/show_bug.cgi?id=52860
    # También se puede controlar a través de un CGI.
    s.headers["TE"] = "gzip"

So, yes, when Apache supports "TE: gzip", there is at least a client who is going to use it :).
Comment 6 Wim Lewis 2016-03-09 02:35:35 UTC
Looking at this patch, I don't understand why it is ignoring the TE: header if the TE token appears in the Connection: header. From my understanding of the Connection: header (RFC 7230 6.1), that should only prevent Apache from forwarding the TE header onwards through a proxy. It shouldn't prevent Apache from interpreting the TE header for itself.