Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FINAL_CONTENT_TYPE set incorrectly when no filters #4744

Closed
michaelrsweet opened this issue Dec 9, 2015 · 2 comments
Closed

FINAL_CONTENT_TYPE set incorrectly when no filters #4744

michaelrsweet opened this issue Dec 9, 2015 · 2 comments
Labels
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

@michaelrsweet michaelrsweet commented Dec 9, 2015

Version: 1.7.0
CUPS.org User: ossman

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.

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Jan 13, 2016

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)

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Jan 14, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant