httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: ContentDigest and filtering
Date Fri, 22 Sep 2000 19:05:22 GMT writes:

> In a message dated 00-09-22 13:55:08 EDT, Greg writes...
> > For right now, I would vote for disabling the function when you know
> > it's going to break, and putting the Content-MD5 filter on the back
> > burner.  I think we have enough alligators gnawing at our ankles at the
> > moment.
> It's really simple. Who OWNS the MD5 cheksum? 
> Is it a CONTENT thing or a TRANSPORT thing?
> If it's a CONTENT thing then it needs to happen just 
> after the final 'filtered' version of the CONTENT and
> right before any TRANSPORT encoding/filtering kicks in.

It's a content thing.

>From RFC 2616 (but I'm guessing that you know this already):

  The MD5 digest is computed based on the content of the entity-body, 
  including any content-coding that has been applied, but not
  including any transfer-encoding applied to the message-body. If the
  message is received with a transfer-encoding, that encoding MUST be
  removed prior to checking the Content-MD5 value against the received

> The MD5 thing won't be the only header value which is
> going to force ( finally ) good separation in the HTTP
> protocol handling of what belongs to the CONTENT ( Presentation )
> layer and what belongs to the Transfer-encoding ( transport )
> layer.

which I take to mean that you think it should only be implemented as a
filter and that there should be no support of it in
default_handler()...  correct interpretation?

Jeff Trawick | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message