- From: Life is hard... and then you die. <Ronald.Tschalaer@psi.ch>
- Date: Thu, 20 Nov 1997 07:16:02 +0100
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> I don't see the point of the trailer field at all. > Why not just say, as suggested: > > Only put fileds in the trailer that can be safely ignored by the > client (e.g., Last-Modified). Content-Length is expressly forbidden in > the trailer and if found MUST be ignored. As a client implementor I strongly support the proposed Trailer field. The reason is that I'm unwilling to calculate an MD5 hash on every response stream just so that if the server happens to send a Content-MD5 trailer I can check it (i.e. I'm in a situation where I don't want to buffer the complete response). With the forward declaration of the Content-MD5 field I can do the calculation only if there will be a Content-MD5 field in the trailer. In that respect, I'd even prefer Trailer field to be *required* (or at least a SHOULD) if a Content-MD5 field will be sent in the trailer. Is there any reason we can't change An HTTP/1.1 sender MAY include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient to know which header fields to expect in the trailer. to An HTTP/1.1 sender SHOULD include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient to know which header fields to expect in the trailer. ? Is this because of already installed implementations? Cheers, Ronald
Received on Wednesday, 19 November 1997 22:17:12 UTC