From owner-freebsd-arch Fri Mar 16 13: 3:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 1880237B718 for ; Fri, 16 Mar 2001 13:03:51 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id NAA11588; Fri, 16 Mar 2001 13:58:09 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp05.primenet.com, id smtpdAAAW_aynu; Fri Mar 16 11:30:52 2001 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA14833; Fri, 16 Mar 2001 11:36:20 -0700 (MST) From: Terry Lambert Message-Id: <200103161836.LAA14833@usr02.primenet.com> Subject: Re: [PATCH] add a SITE MD5 command to ftpd To: dot@dotat.at (Tony Finch) Date: Fri, 16 Mar 2001 18:36:19 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.ORG In-Reply-To: <20010316044655.C385@hand.dotat.at> from "Tony Finch" at Mar 16, 2001 04:46:55 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >The whole idea of HTTP protection like this is pretty inane, since > >we've all already agreed, I think, that it's really only useful > >for mirroring, or for offloading an MD5 calculation from my 800MHz > >Pentium III laptop onto a big, ballsy 66MHz 486 FTP server. > > RFC 2616 section 14.15: > > [...] > The Content-MD5 entity-header field, as defined in RFC 1864 [23], is > an MD5 digest of the entity-body for the purpose of providing an > end-to-end message integrity check (MIC) of the entity-body. (Note: a > MIC is good for detecting accidental modification of the entity-body > in transit, but is not proof against malicious attacks.) > [...] Actually, it would prevent useful modification more often than accidental modification. Accidental modification is nearly impossible; who would do it? The kernel between the time the server writes the bytes, and the TCP stack checksums them? I've suggested twice before that this RFC be updated to indicate that the actual intent of this field is to prevent caches from being efficient and/or doing URL rewriting and/or caching static portions of dynamically generated pages as page elements, without the use of "frames". For example, much as I dislike the fact that they've talked people into their absurd scheme, Akamai would not work very well with this being enforced. Make that three times, now. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message