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.
Regards
Manish
>>> --
> ______________________________________________________________________
> Michael Sweet, Easy Software Products mike at easysw.com> Printing Software for UNIX http://www.easysw.com