Talk:HTTP compression

Please fill it up if u r free, i'm a litl busy so the work is kept pending

Tux the penguin 13:19, 30 April 2006 (UTC)[reply]

I have removed the sentence "Webmasters report a 150-165% performance increase after enabling http compression." because it is not a fact, neither a proper

Jajis 11:04, 7 June 2006 (UTC)[reply]

I've included some information, it's rather a bit update considering the briefness of previous article. However, I think it still requires polishing, as well as hmm, maybe examples of forcing some encryption schema using a server-side scripting language, like PHP. Also, it currently lacks information about the order of coding tokens in case more than 1 compression method is used (e.g. gzip and sdch). Also, a good idea would be to make a "schema support" table with browsers/clients on one side, and coding tokens on the other. Also, comments on usage of word "schema" is welcomed, since I'm not entirely sure if it's OK there. gynvael.coldwind//vx 14:09, 9 May 2010 (UTC)[reply]

I've done some research (as in checking what browser supports what) and it seems that lynx, links, elinks and Chrome support bzip2 (however Chrome does not advertise it), so I've added bzip2 to valid content-coding (it still needs a source, I'll look for it later). Additionally it seems that Microsoft came up with z 'peerdist' protocol (stated as content-coding), that doesn't seems like a compression algorithm, it's more like a peer-to-peer distributing of cached content in office-LANs (it's said to be supported by Windows Server 2008 R2 and Windows 7). Hmm, since this article is about HTTP compression, I'm not sure if peerdist should be described here, but since it's a valid (not in IANA, but supported by a major browser - IE 8 on W7) content-coding token, I've placed it in that section. I'll try to dig a little into the peerdist and write an article about it later. gynvael.coldwind//vx 09:52, 10 May 2010 (UTC)[reply]

I'm adding a "Citation needed" for sdch, bzip2 and peerdist Content-Codings. Neither of them are registered at http://www.iana.org/assignments/http-parameters/http-parameters.xml , and given that registering a name there is almost no effort at all, it's hard to take these seriously. JöG (talk) 22:41, 18 November 2012 (UTC)[reply]

I came past this as I did some web research on the topic. The information on the reference site Compression Tests: About seemed to be plausible and they seem to do continous testing, so I added the information on the content-coding token deflate and the point that Apache mod_deflate only supports gzip. This article should also mention the possibility to compress requests (i.e. POST) from client to server. I.e. mod_deflate refers to that possibility in the section Input Decompression. And this document refers to a 2-way compression How to Use SOAP Compression with Apache Axis 1.X. But right now, I'm not clear enough about it to add it. --Voeren (talk) 16:06, 23 March 2011 (UTC)[reply]

Since RFC2616 there are two ways to negotiate a compression transformation, either via the `Content-Encoding` or via the `Transfer-Encoding` headers. This is currently supported by Opera.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=68517 for more information about this issue. — Preceding unsigned comment added by 85.126.237.90 (talk) 13:01, 30 August 2011 (UTC)[reply]

To be more specific: HTTP 1.1 describes Content-Encoding (you can get the resource named "foo.html" in two flavors, gzipped or plain) and Transfer-Encoding (never mind the flavor of "foo.html", you can receive it using a compressed or uncompressed transport channel). — The RFC makes it quite clear that transfer encoding is the right way to achieve HTTP (transport) compression, and that content-encoding is not. It's a bit disturbing that the article describes the content-encoding hack, and not the correct mechanism. Both should be described, along with their current levels of software and RFC support. JöG (talk) 22:23, 18 November 2012 (UTC)[reply]

The [Tests] resource has pass/fail data for compression. However, a clear picture of whether browsers' implementation of HTTP compression actually has a significant effect on download rate would very much enhance this article. TrainSister (talk) 09:38, 13 December 2011 (UTC)[reply]

Although quite clear in its content, this article did NOT answer my current question (for which I came here): download compression yes, but what about upload compression (of a request from a client to a server)? Is that possible, and if so how? (and if not so, write about it also, don't be shy). AlainR345^{Techno-Wiki-Geek} 17:51, 24 June 2012 (UTC)[reply]

Wikipedia isn't supposed to be a complete reference for everything. Read the RFC: it's very clear on this subject. JöG (talk) 22:24, 18 November 2012 (UTC)[reply]

I just undid some text which said compression cannot be applied to requests. At least a pointer to a particular RFC and section would be nice, even if you think it is clear. Going by the end of https://tools.ietf.org/html/rfc7230#section-3.3.1 (Transfer-Encoding) I think HTTP request message bodies may be compressed (as long as the server supports this, which could be tricky to know in advance). Uploading a compressed file with a compressed Content-Encoding should also be possible. Not sure how well it goes in the real world though. Vadmium (talk, contribs) 07:09, 1 September 2014 (UTC).[reply]