Re: FW: Digest mess

John Franks writes:
    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?

What about specifying, instead, that the Origin-header field carry
the base64 encoding of the headers as they appear in the original
message?  E.g., if the original response looks like:

	HTTP/1.1 200 OK
	Date: Wed, 31 Dec 1997 13:39:48 GMT
	Content-Length: 36
	Connection: transfer-coding
	Last-Modified: Wed, 31 Dec 1997 13:39:40 GMT
	Vegetable: Arugula, "Corn on the Cob";"with-butter"
	Transfer-coding: gzip

and the origin server wants to digest the Content-Length, Last-Modifed,
and Vegetable headers, it would compute the base64 encoding of

	Content-Length: 36
	Last-Modified: Wed, 31 Dec 1997 13:39:40 GMT
	Vegetable: Arugula, "Corn on the Cob";"with-butter"

and then send this base64 value in the "Origin-header" field.
	
This has the benefit that it
	(1) avoids all problems related to quotes and other special
		characters.
	(2) avoids the need to invent a new separator mechanism.
	(3) uses an existing encoding format, which is already
		employed in Digest Authentication, so we know that
		the implementations in question support base64.
	(4) is simple to specify.

base64 does expand the size of the encoding (33%).  It might
make sense to specify that the field carry the base64 encoding
of a compressed form of the headers (using "deflate"?), which
would probably result in a net savings over the original header
sizes.  But I don't think it's worth another food-fight over this
detail.

-Jeff

Received on Wednesday, 31 December 1997 15:11:42 UTC