Re: CHUNKEDTRAILERS, attempted fix 2

I'm comfortable with Roy & Henrik's proposal, but I have a small qualm
about this wording:

    A server using chunked transfer-coding in a response MUST NOT
    use the trailer for any header fields unless at least one of
    the following is true:

       a) ....

       b) the server grants the recipient(s) the right and ability to
          discard those trailer fields without forwarding them to any
          downstream recipient of the remaining message.  This is
          only possible if the trailer fields consist entirely of
          optional metadata that is not necessary for the recipient
          to understand in order to use the message.

The use of the verb "grants" here implies some sort of specific
action on the part of the server, which of course is not the case.
In fact, the second sentence does a better job of specifying the
conditions under which an exception can be made ... the phrase
"this is only possible if" is a good tip-off.

Also, the use of the term "server" instead of "origin server"
improperly (I think) allows an intervening proxy to "grant"
the right to drop metadata that the actual origin server might
consider "mandatory."

I would suggest using something more like:

       b) The server is the origin server for the response, the
          trailer fields consist entirely of optional metadata,
	  and the recipient could use the message (in a manner
	  acceptable to the origin server) without receiving this
	  metadata.  In other words, the origin server is willing
	  to accept the possibility that the trailer fields might
	  be silently discarded along the path to the client.

Also, two minor nits about the explanatory paragraph that follows:

    The above requirement exists to avoid an interoperabilty paradox
    when the message is being received by an HTTP/1.1 (or later) proxy
    and forwarded to an HTTP/1.0 recipient.  It avoids a situation
    where compliance with the protocol would have necessitated an
    infinite buffer on the proxy.

There's a spelling error, and the use of "paradox" here doesn't
match any of the definitions in my dictionary.  I'd suggest:

    This requirement prevents an interoperability failure
    when the message is being received by an HTTP/1.1 (or later) proxy
    and forwarded to an HTTP/1.0 recipient.  It avoids a situation
    where compliance with the protocol would have necessitated an
    infinite buffer on the proxy.

-Jeff

Received on Wednesday, 26 August 1998 16:39:46 UTC