W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1999

RE: IPP> Chunking Explanation

From: <kugler@us.ibm.com>
Date: Thu, 21 Jan 1999 10:20:12 -0700
To: Stefan Andersson <stefan.andersson@axis.com>
Cc: "Wagner,William" <bwagner@digprod.com>, harryl@us.ibm.com, ipp@pwg.org, http-wg@hplb.hpl.hp.com
Message-Id: <87256700.005F3DC7.00@d53mta08h.boulder.ibm.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/308


I agree with you, however, this started out as a direct quote from the spec

draft-ietf-http-v11-spec-rev-06: 10.4.14      413 Request Entity Too Large
The server is refusing to process a request because the request entity is
larger than the server is willing or able to process. The server MAY close
the connection to prevent the client from continuing the request.

It seems the 413 is a special case of 4xx.


Stefan Andersson <stefan.andersson@axis.com> on 01/21/99 05:34:01 AM

Please respond to Stefan Andersson <stefan.andersson@axis.com>

To:   "Wagner,William" <bwagner@digprod.com>
cc:   Harry Lewis/Boulder/IBM, Carl Kugler/Boulder/IBM, ipp@pwg.org
Subject:  RE: IPP> Chunking Explanation

On Wed, 20 Jan 1999, Wagner,William wrote:
> RFC2068 requires HTTP1.1 Servers to support both Content Length and
> Chunking for all requests.  However, some IPP servers may exist that
> do not support Chunking. In this case, the IPP server may return error
> 411(Length Required) in response to the HTTP POST.
> Further,  some IPP servers may implement a filter-and-buffer approach to
> determine CONTENT_LENGTH from a chunked encoding before passing the
> request body to a CGI application.  If the buffered request grows too
> the server may reject the request with status code 413 (Request Entity
> Large). If this occurs, the IPP server may also close the connection to
> prevent the client from continuing the request.
If the server can't ensure that the client has acknowledged the response
it's better to consume the rest of the data, this is to make sure that the
client reads the response.

draft-ietf-http-v11-spec-rev-06: 10.4 Client Error 4xx
   If the client is sending data, a server implementation using TCP
   SHOULD be careful to ensure that the client acknowledges receipt of
   the packet(s) containing the response, before the server closes the
   input connection. If the client continues sending data to the server
   after the close, the server's TCP stack will send a reset packet to
   the client, which may erase the client's unacknowledged input buffers
   before they can be read and interpreted by the HTTP application.


Stefan Andersson                         Software Engineer
Print Server Business Unit               Stefan.Andersson@axis.com
AXIS Communications AB                   Phone: +46 46 270 19 85
Scheelevägen 16                          Fax: +46 46 13 61 30
S-223 70  LUND, SWEDEN                   http://www.axis.com
Received on Thursday, 21 January 1999 09:26:16 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:06 UTC