Re: [RFC] Have-Digest and duplicate transfer suppression

tor 2011-08-11 klockan 12:12 -0600 skrev Alex Rousskov:

> IMO, just like with Content-MD5, intermediaries MUST NOT set end-to-end
> checksums or such checksums would become useless for what they were
> designed for.

Intermediaries are allowed to add Digest: headers to messages. A
strictly transparent proxy (in RFC2616 terms) probably SHOULD NOT, but
any other MAY. But then a strictly transparent proxy should probably not
be doing any duplicate transfer suppression either.

Digest if used in a request would apply to the enclosed instance (i.e.
PUT body), not the servers representation at the requested URL.

Normal GET requests do not describe some instance and thus Digest can
not be computed on them.

Digest is not a condition header. Only a descriptive header.

> IMO, we should not violate the intent of the RFC authors when reusing
> their stuff. If we do not agree what their intent was, we can ask them
> to clarify, but even that is not 100% safe as there might be competing
> implementations out there that would use a different interpretation. For
> small things, it may not matter much, but end-to-end guarantees are no
> small things, IMO.

Agreed in principle. But HTTP do not provide any such end-to-end
guarantee. Digest certainly do not and was not their intention.

See for example the paper you referenced earlier where they explicitly
mention the fact that Digest may be added by intermediaries as a benefit
compared to Content-MD5 which has a much more restricted use.

> If we use the If-None-Match approach, it would be just
>
> If-None-Match: edigest_md5=foo
>
> or similar.

If-None-Match syntax do not allow for extensions.

      If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
      entity-tag = [ weak ] opaque-tag
      weak = "W/"
      opaque-tag = quoted-string

But yes, it can obviously be extended in non-ambiguous ways without
conflicting with existing use. But any such extensions need to be
enabled carefully as we cannot assume the receiving end can parse them
at all and may reject the header of complete message as invalid.

Regards
Henrik
Received on Sun Aug 14 2011 - 11:13:21 MDT