HTTP compression: Difference between revisions

Content deleted Content added
No edit summary
No edit summary
Line 2:
'''HTTP compression''' is a capability that can be built into [[web server]]s and [[web client]]s to improve transfer speed and bandwidth utilization.<ref>{{cite web|url=http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true|title=Using HTTP Compression (IIS 6.0)|access-date=9 February 2010|publisher=Microsoft Corporation}}</ref>
 
HTTP data is [[Data compression|compressed]] before it is sent from the server: compliant browsers will announce what methods are supported to the server before downloading the correct format; browsers that do not support compliant compression method will download uncompressed data. The most common compression schemes include [[gzip]] and [[Brotli]]; however, a full list of available schemes is maintained by the [[Internet Assigned Numbers Authority|IANA]].<ref>RFC 2616, Section 3.5: "The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens."</ref> Additionally, third parties develop new methods and include them in their products, such as the Google [[Shared Dictionary Compression for HTTP]] (SDCH) scheme implemented in the [[Google Chrome]] browser and used on Google servers.
 
There are two different ways compression can be done in HTTP. At a lower level, a Transfer-Encoding header field may indicate the payload of an HTTP message is compressed. At a higher level, a Content-Encoding header field may indicate that a resource being transferred, cached, or otherwise referenced is compressed. Compression using Content-Encoding is more widely supported than Transfer-Encoding, and some browsers do not advertise support for Transfer-Encoding compression to avoid triggering bugs in servers.<ref>[https://code.google.com/p/chromium/issues/detail?id=94730 'RFC2616 "Transfer-Encoding: gzip, chunked" not handled properly'], [[Chromium (browser)|Chromium]] Issue 94730</ref>
 
==Compression scheme negotiation==
In most cases, excluding the SDCH, theThe negotiation is done in two steps, described in RFC 2616:
 
1. The [[web client]] advertises which compression schemes it supports by including a list of tokens in the [[HTTP request]]. For ''Content-Encoding'', the list is in a field called ''Accept-Encoding''; for ''Transfer-Encoding'', the field is called ''TE''.
Line 30:
 
The [[web server]] is by no means obligated to use any compression method&nbsp;– this depends on the internal settings of the web server and also may depend on the internal architecture of the website in question.
 
In case of SDCH a dictionary negotiation is also required, which may involve additional steps, like downloading a proper dictionary from the external server.
 
==Content-Encoding tokens==
Line 51 ⟶ 49:
*peerdist<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/dd304322%28v=PROT.10%29.aspx|title=[MS-PCCRTP]: Peer Content Caching and Retrieval: Hypertext Transfer Protocol (HTTP) Extensions|publisher=Microsoft|access-date=19 April 2014}}</ref> – Microsoft Peer Content Caching and Retrieval
*[[rsync]]<ref>{{cite web |title=rproxy: Protocol Definition for HTTP rsync Encoding |url=https://rproxy.samba.org/doc/protocol/protocol.html |website=rproxy.samba.org}}</ref> - [[Delta_encoding#Delta_encoding_in_HTTP|delta encoding in HTTP]], implemented by a pair of ''rproxy'' proxies.
*[[sdch]]<ref>{{cite web|url=http://lists.w3.org/Archives/Public/ietf-http-wg/2008JulSep/att-0441/Shared_Dictionary_Compression_over_HTTP.pdf|title=A Proposal for Shared Dictionary Compression Over HTTP|publisher=Google|last1=Butler|first1=Jon|author2=Wei-Hsin Lee|last3=McQuade|first3=Bryan|last4=Mixter|first4=Kenneth}}</ref><ref>{{cite web|url=https://groups.google.com/forum/#!forum/SDCH|title=SDCH Mailing List|publisher=Google Groups}}</ref> – Google Shared Dictionary Compression for HTTP, based on [[VCDIFF]] (RFC 3284)
*xpress - Microsoft compression protocol used by Windows&nbsp;8 and later for Windows Store application updates. [[LZ77_and_LZ78#LZ77|LZ77]]-based compression optionally using a Huffman encoding.<ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/Hh554002.aspx|title=[MS-XCA]: Xpress Compression Algorithm|access-date=29 August 2015}}</ref>
*[[XZ Utils|xz]] - LZMA2-based content compression, supported by a non-official Firefox patch;<ref>{{cite web|url=https://wiki.mozilla.org/LZMA2_Compression|title=LZMA2 Compression - MozillaWiki|access-date=18 April 2014}}</ref> and fully implemented in mget since 2013-12-31.<ref>{{cite web|url=https://github.com/rockdaboot/mget|title=mget GitHub project page|access-date=6 January 2017}}</ref>