Wouldn't it make more sense to use a self-descriptive digest?
In other words, send a list of the header field-names and other properties
that are being digested, rather than listing their values, and
then let the applications adjust what is being digested if there
are persistent failures. That would cover all of the problems
discussed and allow for the complete extensibility desired by WebDAV.
It also fixes the problem that Dave was trying to describe, namely
that if the values are separate then the recipient would still have
to compare the received field values against the received values
inside dheader-content, which would still result in failure if the
proxy changes them. (If it didn't compare them, then an attacker
could simply change the field values without changing the digest
at all.)
If you change the definition of entity-digest (which seems unavoidable
at this point) then you should also change the "digest" parameter
name to something else and deprecate "digest". This is necessary for
deployment reasons, even if everyone agrees to implement the new spec.
After all, HTTP date formats were screwed up because they were implemented
by reference to an obsolete specification (RFC 850) long after it became
obsolete.
....Roy