Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Mar 2001 18:36:19 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        dot@dotat.at (Tony Finch)
Cc:        tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.ORG
Subject:   Re: [PATCH] add a SITE MD5 command to ftpd
Message-ID:  <200103161836.LAA14833@usr02.primenet.com>
In-Reply-To: <20010316044655.C385@hand.dotat.at> from "Tony Finch" at Mar 16, 2001 04:46:55 AM

next in thread | previous in thread | raw e-mail | index | archive | help
> >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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103161836.LAA14833>