Bug#729713: libcups2: fails to fetch ppd of ipp:// device
On 01/05/2014 01:36 PM, Wolfgang Walter wrote:
> On Sunday 05 January 2014 13:12:31 Till Kamppeter wrote:
>> On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote:
>>> Control: tags -1 +moreinfo
>>>
>>> Hi Lionel and Wolfgang,
>>> hi Till,
>>>
>>> thanks for your detailed bugreports and proposed patch.
>>>
>>> Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane a écrit :
>>>> Let FOO be a printer configured in CUPS with an
>>>> ipp://foo.localdomain.tld/something device uri.
>>>> Mine is a Konica Minolto C353.
>>>>
>>>> All cups clients fail to show printing options.
>>>>
>>>> "lpoptions -d FOO -l" says:
>>>> lpoptions: Unable to get PPD file for FOO: Not Found
>>>>
>>>> A wireshark shows a request for http://device_ip:631/ipp.ppd,
>>>> to which the printer replies by a 404.
>>>>
>>>> The attached patch disables that undesirable behaviour, which is new
>>>> in 1.6 (did not happen in 1.5).
>>>
>>> Your proposed patch is functionally equivalent to disabling the get-ppd-
>>> file-for-statically-configured-ipp-shared-queues.patch , which was
>>> introduced in 1.6.1-1 as a backport from upstream's fix for
>>> http://cups.org/str.php?L4178
>>>
>>> Till, as you wrote this patch, what do you think about this?
>>>
>>> Apparently, http://cups.org/str.php?L4159 was related to this problem
>>> and got solved differently in 1.6.2, and now cups/util.c appears to be
>>> redundant around this codeblock.
>>>
>>> Till, can we remove this patch on all versions > 1.6.2 ?
>>
>> Important is to check whether if you create a raw IPP queue pointing to
>> a CUPS queue on a remote server that you get access to the options on
>> the client (means that the client loads the PPD from the server). Please
>> test this.
>>
>> You can test by creating an arbitrary print queue with PPD on one
>> machine (the server) and sharing it. On another machine (the client) you
>> either create a raw ipp: or ipps: queue pointing to the queue on the
>> server or you run cups-browsed (which creates such a queue
>> automatically). If you print out of a GUI app on the client using the
>> ipp/ipps queue pointing to the CUPS server you should see the PPD
>> options in the print dialog. You should also run "lpoptions -p <printer>
>> -l" on the client and should see the options if <printer> is an ipp/ipps
>> queue pointing to the server and no error message if <printer> is
>> pointing to a native IPP printer.
>>
>> Till
>
> We do not have a cups-server running on the client. Our configuration is:
>
> client: only
> /etc/cups/client.conf with
> ServerName cups.localdomain.tld.
>
> On the print server cups.localdomain.tld. we have a lot of printers in
> printers.conf like that
>
> <Printer Mehltau>
> AuthInfoRequired none
> Info Mehltau
> Location Rosenstraße
> MakeModel MyFavoritePostscripPrinterModel
> DeviceURI ipp://mehltau.drucker.localdomain.tld/ipp
> State Idle
> StateTime 1387541234
> Type 8425548
> Filter application/vnd.cups-raw 0 -
> Filter application/vnd.cups-command 0 commandtops
> Filter application/vnd.cups-postscript 0 -
> Accepting Yes
> Shared Yes
> JobSheets none none
> QuotaPeriod 0
> PageLimit 0
> KLimit 0
> OpPolicy default
> ErrorPolicy abort-job
> </Printer>
>
> We do not wan't to mehltau to be a raw-printer as the printer server should
> e.g. handle pdfs etc.
>
> This setting breaks with cups 1.6. as now the client contacts
> cups.localdomain.tld but then tries to get the ppd from
> mehltau.drucker.localdomain.tld instead from cups.localdomain.tld
>
> But mehltau.drucker.localdomain.tld is a ipp postscript printer (e.g. from HP
> or any other vendor) and does not provide ppds (and in our case the client is
> not even allowed to communicate with Mehltau directly).
>
> Regards,
>
My patch did
httpSeparateURI(HTTP_URI_CODING_ALL,
device_uri,
scheme, sizeof(scheme), username,sizeof(username),
host, hostsize, port, resource, resourcesize);
whereas the final fix does
httpSeparateURI(HTTP_URI_CODING_ALL,
_httpResolveURI(device_uri, uri, sizeof(uri),
_HTTP_RESOLVE_DEFAULT, NULL,NULL),
scheme, sizeof(scheme), username,sizeof(username),
host, hostsize, port, resource, resourcesize);
Can it be that the _httpResolveURI() causes some problem here?
Till
Reply to: