- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 27 May 2014 10:46:49 +0000
- To: Chris Drechsler <chris.drechsler@etit.tu-chemnitz.de>
- cc: ietf-http-wg@w3.org
In message <53846489.9010905@etit.tu-chemnitz.de>, Chris Drechsler writes: >Am 23.05.2014 16:20, schrieb Poul-Henning Kamp: >> Although I have yet to see any non-contrived examples, there is >> absolutely nothing preventing the exact same body from having >> two entirely different meanings, depending on the headers. >> >> For instance: >> Content-Encoding: gzip >> Content-Type: text/html >> <gzip'ed body> >> vs. >> Content-Type: application/x-gzip >> <exact same gzip'ed body> >> >> Are two very different responses for any sensible client, yet your >> proposal would deliver either one for the other. > >In the first case the input is for example an html document and the >server computes the SHA256 value before the document is compressed >[...] >In the second case the input is an already compressed file, e.g. >foo.html.gz. It will not be compressed again by the server during the >process of sending (no Content-Encoding is applied). The SHA256 value is >different to the former case: Would you be surprised if I tell you that most high-performance servers and caches try their damnest to avoid running a gzip compressor during delivery ? In the first case the server would often have to run a gzip decompressor to calculate the SHA256... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Tuesday, 27 May 2014 10:47:14 UTC