W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1997

RE: FW: Digest mess

From: Yaron Goland <yarong@microsoft.com>
Date: Wed, 31 Dec 1997 12:29:07 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D0E71A5@red-msg-59.dns.microsoft.com>
To: "'John Franks'" <john@math.nwu.edu>
Cc: "'ietf-http-wg@w3.org'" <ietf-http-wg@w3.org>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
So it seems we are in agreement. By adding the ability to support an
arbitrary list of headers in the digest, we make Digest usable by DAV and
everyone else.


> -----Original Message-----
> From:	John Franks [SMTP:john@math.nwu.edu]
> Sent:	Wednesday, December 31, 1997 11:40 AM
> To:	Yaron Goland
> Cc:	'ietf-http-wg@w3.org'; http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject:	Re: FW: Digest mess
> > > 
> > > The main thing I hate about Digest is:
> > > 
> > > A) Can't digest arbitrary headers.
> > > 
> > > This is a big deal for groups like WebDAV where new headers are being
> > > introduced which contain critical command information. For example the
> > > depth header specifies if a command applies to a single resource or a
> > > collection of resources. The destination header specifies the
> destination
> > > of a move or copy. Changing these headers would have a profound effect
> on
> > > the meaning of the method.
> > > 
> As you probably know from the discussion in this group the difficulty
> with digesting headers is that proxies may modify them.  Proxies
> may add headers which were not originally present, may change them,
> or may "canonicalize" them.  All of these features would ruin a
> digest.
> It has proven difficult if not impossible to have the specification
> require that proxies not change all the headers people would like
> digested.  My guess is that it is futile to try to specify a set of
> headers which must always be digested and must not be changed by
> proxies.  At least the discussion so far has not shown anything like a
> consensus on this.
> On the other hand I agree that digesting arbitrary headers is highly
> desirable.  Painful though it may be in terms of bandwidth, the only
> way I think this can be done is by replicating all the relevant origin
> server headers in a field of the Authentication-info header.  Proxies
> are required not to touch the Authentication-info header.
> This "origin-header" field would have a value which is a quoted string
> consisting of the concatenation (with some separator) of the complete
> headers which the sender wants digested.  This string would be included
> in the material digested to form the entity-digest.
> This would have the advantage of being extensible as any new headers
> are added.
> I am not sure what a good separator would be; colon might not work
> too well.  Also I don't know what to do about headers containing
> quotation marks.  Perhaps something like %-escapes for colons, quotes
> and percents in the headers being concatenated and colon as separator?
> John Franks
> john@math.nwu.edu
Received on Wednesday, 31 December 1997 15:30:14 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC