- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 18 Nov 97 18:07:32 PST
- 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 UTC