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

Re: HTTP/1.1 ISSUE: TRAILER_FIELDS - Proposed Resolution

From: Life is hard... and then you die. <Ronald.Tschalaer@psi.ch>
Date: Thu, 20 Nov 1997 07:16:02 +0100
Message-Id: <3473D5A2.4FE87BBE@psi.ch>
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:03 EDT