RFC 3196, "Internet Printing Protocol/1.1: Implementor's Guide", November 2001Source of RFC: ipp (app)
See Also: RFC 3196 w/ inline errata
Errata ID: 2924
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-08-08
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12
Section 18.104.22.168.1 says:
The Printer object MUST return one of the following "status-code" values for the indicated reason. Whether all of the document data has been accepted or not before returning the success or error response depends on implementation. See Section 13 in [RFC2911] for a more complete description of each status code.
It should say:
The Printer object MUST return one of the following "status-code" values for the indicated reason. The Printer object MUST accept all document data before returning the success or error response. See Section 13 in [RFC2911] for a more complete description of each status code.
HTTP (RFC 2616) classifies POST as a non-idempotent method, so a conforming server implementation may only return an error status or 100-continue as described in sections 22.214.171.124 and 8.2.2 of RFC 2616. Essentially, the printer cannot respond to the POST until it has processed all of the request message body, otherwise how would it report chunking or other protocol errors? And how would a client reliably send or a server reliably process multiple IPP requests (as POST messages) when a server provides an early response?