|Summary:||Support Transfer-Encoding: gzip|
|Product:||Apache httpd-2||Reporter:||Tim B <isoma>|
|Component:||mod_deflate||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|Severity:||enhancement||CC:||ian, takashi.asfbugzilla, wiml|
patch against trunk r1298556
patch against trunk r1376741
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 1 Tim B 2012-03-08 21:15:31 UTC
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.