FINAL_CONTENT_TYPE set incorrectly when no filters #4744
FINAL_CONTENT_TYPE is set incorrectly when no filters are needed. Reading the code this seems to have been broken by r11147 which dates all the way back from 1.7.0.
That commit added a fallback to set FINAL_CONTENT_TYPE to "printer/" when no other content type was found. It references rdar://problem/14355011, so I don't know exactly what problem it is trying to solve.
The short description is however that FINAL_CONTENT_TYPE was missing, which was indeed the behaviour before 1.7.0. But I think this fix is wrong because it means that FINAL_CONTENT_TYPE now no longer contains the actual content type of the data, in stark contrast to when filters are actually involved.
I think the proper fix is simply to use the incoming content type, which is the correct type since no filters were involved so the data never changed.
The text was updated successfully, but these errors were encountered:
CUPS.org User: mike
The change was made to avoid having job options getting passed by the IPP backend for file formats that the driver explicitly supports, which is still an issue. So this is working as designed.
(the CONTENT_TYPE environment variable still contains the original file format)
CUPS.org User: ossman
Sorry, but I don't follow.
Why would you want the options dropped? If there have been no filters then the options can not have been integrated into the data. So dropping them would mean they get entirely lost. That can't be what the user wants?
And doesn't the ipp backend use FINAL_CONTENT_TYPE to determine the content type used in the outgoing request? If it always starts sending application/octet-stream there, then it seems rather pointless to even have content type in the IPP protocol? We don't want to start relying on every component having to re-detect the type, which might not even be possible for some types of data.
And even if this somehow is sensible, how is a backend supposed to know if CONTENT_TYPE or FINAL_CONTENT_TYPE contains the content type of the incoming data? Looking for printer/* in FINAL_CONTENT_TYPE seems like a crude hack, and also an unreliable one as there has historically been bugs that caused that for other reasons.