- 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
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 john@math.nwu.edu
Received on Wednesday, 31 December 1997 15:55:43 UTC