Re: HTTP/1.1 ISSUE: TRAILER_FIELDS - Proposed Resolution
Life is hard... and then you die. (Ronald.Tschalaer@psi.ch)
Thu, 20 Nov 1997 07:16:02 +0100
> 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