- From: David W. Morris <dwm@xpasc.com>
- Date: Wed, 31 Dec 1997 13:20:41 -0800 (PST)
- To: Ben Laurie <ben@algroup.co.uk>
- cc: Jeffrey Mogul <mogul@pa.dec.com>, "'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, Ben Laurie wrote: > > 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). In either case, imbeded LWS must be allowed to follow the spirit of possibly continued header values and headers which may be too long. Also, they encoding rule should probably be something like: 1. Compose the subset of headers to be digested 2. Combine into a single string with CR/LF between headers 3. Encode the whole string. In otherwords, encode exactly what would have been sent over the wire from the server. Then all existing rules for separation, etc. just apply after decoding. Dave Morris
Received on Wednesday, 31 December 1997 16:24:34 UTC