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

Re: Accept-Transfer header field (was HTTP/1.1 Issues: TRAILER_FIELDS)

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 18 Nov 97 18:07:32 PST
Message-Id: <9711190207.AA01495@acetes.pa.dec.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Roy Fielding writes:

    >    Likewise, chunked and identity are always required -- there is no
    >    reasonable use for refusal based on lack-of-encoding.  Thus, the only
    >    feature we actually need is the ability to request a given
    >    transfer-encoding be used.
    >    
    >I disagree.  With respect to "chunked", we could presumably change
    >	All HTTP/1.1 applications MUST be able to receive and decode
    >        the "chunked" transfer coding,
    >to
    >	All HTTP/1.1 applications MUST be able to receive and decode
    >        the "chunked" transfer coding, except for clients that
    >	explicitly reject this transfer coding using a qvalue of 0
    >	in an Accept-Transfer request header field.
    >
    >I'm not necessarily saying that we should do this, but it seems
    >safe to do so, and it might pay off for implementors of clients
    >with limited code space.
    
    No, we can't do that.  That has been written in stone (i.e.,
    deployed code).  It is also not desirable from a robustness
    perspective -- HTTP needs an indicator of message length in order
    to differentiate between complete and incomplete responses.  HTTP
    is unsafe for data transfer without that information, so we don't
    give the compliant application any choice.

Oops, Roy is right about this one.  I was rushing, and forgot
about the deployed base of chunk-sending applications.

-Jeff
Received on Tuesday, 18 November 1997 18:13:58 EST

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