Print-Job requests may include duplicate document-format attributes, causing printer rejection

[zhouliang-gif]

Description:

When submitting a Print-Job request via CUPS, the document-format attribute can be added twice, which violates the IPP specification (RFC 8011) that defines document-format as a single-value operation attribute. This duplication can cause the IPP printer which I was testing to reject the job.

Specifically, in backend/ipp.c, the new_request() function adds document-format if format is provided and the operation is not Create-Job:

if (format && op != IPP_OP_CREATE_JOB)
{
    ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_MIMETYPE, "document-format", NULL, format);
    fprintf(stderr, "DEBUG: document-format=\"%s\"\n", format);
}

Later, cupsEncodeOptions2() is called (around line 2991), which adds document-format again when processing job options for Print-Job:

if (group_tag == IPP_TAG_OPERATION && (op == IPP_OP_PRINT_JOB || ...))
{
    if ((val = (char *)cupsGetOption("document-format", num_options, options)) != NULL)
        ippAddString(ipp, IPP_TAG_OPERATION, IPP_TAG_MIMETYPE, "document-format", NULL, val);
    else if (cupsGetOption("raw", ...))
        ...
    else
        ippAddString(..., "application/octet-stream");
}

As a result, the final IPP request may contain two document-format attributes.

This redundancy leads to job rejection by strict IPP implementations.

The response of Get-Printer-Attributes from the printer is:

Do you have any recommendations on the proper way to handle this? Should new_request() avoid setting document-format when it’s already in the options? Or should cupsEncodeOptions2() check for an existing attribute before adding one? Thanks!

[174381115]

This is a supplement to the above information. The printer doesn't support media_col_support attributes, it implement the IPP 1.0 protocol, is this cause the issue ?

[michaelrsweet]

@174381115 The attribute dump indicates the printer still supports IPP/1.1, but regardless I don't think that is the issue.

Investigating...

[SagarJadhav30]

When the backend receives CUPS_SC_CMD_DRAIN_OUTPUT
It sets g.drain_output = 1
The ACK response is sent immediately from the side-channel thread
It no longer depends on the read thread

[SagarJadhav30]

I fixed a race condition in the CUPS USB backend by decoupling side-channel responses from the read thread, eliminating deadlocks and ensuring deterministic output flushing for time-critical bi-directional printers.