IPP Mail Archive: Re: IPP> Is chunking at IPP client end possible?

IPP Mail Archive: Re: IPP> Is chunking at IPP client end possible?

Re: IPP> Is chunking at IPP client end possible?

Manish Thakur (manish@teil.soft.net)
Thu, 10 Dec 1998 12:36:31 +0530

Michael Sweet wrote:

> Manish Thakur wrote:
> > ...
> > IPP does not have an attribute to indicate end of document
> > chunk, if client end decides to chunk a large print data file (of the
> HTTP provides the chunking support, so any compliant client (or server)
> must handle the chunking, with a 0-length chunk indicating the end of
> the data.

> From the above explanation I understand that IPP client can divide a
> large IPP operational data prepared, into multiple http requests at the
> client end; the last request is made with zero length. Is it correct?

> The protocol does not make it mandatory to send a zero length request
> after sending operational data. Is it correct? So if all the operational
> data is sent in a single request, how does the IPP server understand that
> it has recieved all the data for the request?

> > order of 100 Mbs) before sending to server end. Is this understanding
> > correct? If yes what could be the possible solution for handling
> > phenominally large print data file.
> The IPP/HTTP server can send an error message (request-too-large or
> something similar) and ignore print data once it exceeds the server
> limit. By ignoring I mean that the server will continue to read the
> data file sent by the client, but it won't store the data for later
> use. This means that the client won't know that the data file is too
> large until is has been sent in its entirety, however HTTP doesn't
> provide a method for stopping a request short of closing the client
> connection.

I see job-k-octets as an optional attribute in Job Template Attributes, is
this relevant in this context?
Can a IPP server handle print data that has come across via multiple http
requests from the client, without using job-k-octets attribute?

Sorry this is a big one, any info will be appreciated.

> --
> ______________________________________________________________________
> Michael Sweet, Easy Software Products mike@easysw.com
> Printing Software for UNIX http://www.easysw.com