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

Re: FW: Digest mess

From: John Franks <john@math.nwu.edu>
Date: Wed, 31 Dec 1997 14:55:30 -0600 (CST)
To: Jeffrey Mogul <mogul@pa.dec.com>
cc: "'ietf-http-wg@w3.org'" <ietf-http-wg@w3.org>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-ID: <Pine.LNX.3.96.971231143921.2809A-100000@hopf.math.nwu.edu>
On Wed, 31 Dec 1997, Jeffrey Mogul wrote:

> What about specifying, instead, that the Origin-header field carry
> the base64 encoding of the headers as they appear in the original
> message? 

> 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%).

Well, in principle I agree.  But I have some reservations.  Actually
base64 is used in Basic authentication, but not in digest.  It is a
messy translation to implement because it requires manipulation of
bits not just octets.  If we had it to do over again I would argue
against its use in Basic authentication, in favor of something much
simpler with the same functionality.  Right now I suspect that most
servers contain routines for decoding base64, but not encoding and most
clients have routines for encoding and not decoding.  At least that is
all that is used by Basic authentication.

If we imagine a day when Basic no longer exists there will be no
need for base64 in server or client.

What about using something much simpler and more readable like 
%-encoding all non-alphanumerics in the headers?  This also
expands the size somewhat, but I think the advantages you list
are worth the cost.

John Franks
Received on Wednesday, 31 December 1997 15:55:43 UTC

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