Re: Transfer-Encoding: questions not answered

>Scanning some back email, I found these questions that I had posed about
>Transfer-Encoding, but that I don't think got answered.

I don't like answering questions -- questioning answers is much easier.  ;-)

>1)  Should the [HTTP/1.2] specification state when "chunked" must and
>must not be used?  Although there's no consensus session/keepalive
>proposal, obviously any content sent from the server to the client for
>a held-open connection must either have a Content-Length or be
>chunked for the connection to remain open.

It will state when a length (chunked or CL) must be given, yes.

>2) Can a client send chunked content in a POST in lieu of a
>Content-Length, or even with a C-L?  (And what does it mean to have
>both, especially if they disagree?)

Only when talking to a server that it knows will support chunked messages.
If both are given, CL is overridden.

>3) If (2) is true, does the CGI interface change to require a CGI script
>to interpret T-E, or does the interface stay the same, and the server
>processes the chunked content and passes the concatenated chunks to the
>CGI?  If the latter, is it valid for the server to forge a Content-Length
>header for the CGI to use to read the concatenated content where none
>existed previously?
>[As Larry Masinter pointed out, the CGI interface is outside the scope of
>this list, but changes to HTTP can affect it.]

CGI is outside the scope of this list, period.  CGI will have to be updated
no matter what changes are made to HTTP, but that update is an issue for
server developers and the WWW.  CGI is not an IETF protocol; it is a
server-side API.

 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
                      (fielding@w3.org)                (fielding@ics.uci.edu)

Received on Friday, 18 August 1995 10:17:02 UTC