Re: FW: Digest mess

Jeffrey Mogul wrote:
> 
> 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.

It's a shame we have come to this pass, but I'm beginning to think that
it is the only answer. Base64 is one answer, but wouldn't URL encoding
also be easy enough and more compact?

If a cheap and easy to implement compression scheme can be used, then
why not? (In which case, I'd guess base64 becomes a good idea).

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Received on Wednesday, 31 December 1997 15:37:07 UTC