- From: Dave Kristol <dmk@allegra.att.com>
- Date: Wed, 7 Feb 96 14:23:56 EST
- To: hallam@w3.org
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
hallam@w3.org wrote on Wed, 07 Feb 96 13:24:54 -0500: > I am trying to produce a spec for signatures and authentication info in HTTP > messages. There are two options: > > 1) Produce something broken which some people will like on artistic grounds > 2) Find a way of attacking the signatures to the _end_ of the message. [... lots of stuff elided] I'll pass on MIME purity and propose the following. The idea is to allow headers at the end of a response, with a hint about them at the beginning. A pre-requisite is that the actual content must have a discernible length, one way or another. Here's how such a response would look: 1) The server includes the following among the response headers: At-end: hdr1, hdr2 where hdr1 and hdr2 (etc.) are response headers that will come after the entity. That way the client will know what to expect later. 2) The entity must have an associated length via one of: - Content-Length - Transfer-encoding: chunked - MIME multi-part encapsulation 3) If there was an At-end response header, the client expects to see one or more additional response headers, followed by a blank line. The client need only heed headers named in the At-end header. (That's not essential to the proposal -- it's just sanitation.) It is an error (whatever that means) for a header promised in At-end to be missing. Dave Kristol
Received on Wednesday, 7 February 1996 11:33:26 UTC