Bug 44665 - Message "IPP request failed" if /classes cannot be accessed
Summary: Message "IPP request failed" if /classes cannot be accessed
Status: CLOSED WORKSFORME
Alias: None
Product: kdeprint
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: KDEPrint Devel Mailinglist
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-07-03 14:48 UTC by Martin Kiehne
Modified: 2008-12-31 12:13 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Kiehne 2002-07-03 14:36:34 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kdeprint
Version:           KDE 3.0.2 
Severity:          wishlist
Installed from:    Compiled From Sources
Compiler:          Not Specified
OS:                Linux
OS/Compiler notes: Not Specified

I always got the following error message when starting kprinter: "An error occurred while retrieving the printer list: The IPP request failed for an unknown reason." After clicking "OK" kprinter worked fine.

strace showed that kprinter tried to access the /classes resource on our cups-server. Since we don't have any classes defined we blocked the access:

send(12 "POST /classes/ HTTP/1.1\r\n" 25 0) = 25
[...]
recv(12 "HTTP/1.1 403 Forbidden\r\n" 2048 0) = 24

Removing the appropriate <Location ...> from the cupsd.conf fixed the problem. 

Is it possible to detect that problem (403 Forbidden) and produce a more meaningful error message or (since printer classes aren't mandatory for using cups) don't display that error?

(Submitted via bugs.kde.org)
Comment 1 Michael Goffioul 2002-07-05 09:37:03 UTC
What you're asking is a little bit tricky. Indeed the error message
you get means actually that KDEPrint doesn't know why the request
failed. So it can be intentional (like in your case) but it might
also be due to some other reasons in which case mmost of the users
would want to be notified about the problem.

I can try to find a better solution but first of all I need at least
to reproduce it which I can't. How did you disable the classes? I
tried locally by adding:

<Location /classes>
Order DenyAllow
Deny From All
</Location>

to the configuration but this doesn't seem to have the desired effect.

Michael.

-- 
------------------------------------------------------------------
Michael GoffioulIMEC-DESICS-MIRA
e-mail: goffioul@imec.be(Mixed-Signal and RF Applications)
Tel:    +32/16/28-8510Kapeldreef 75
Fax:    +32/16/28-15153001 HEVERLEE BELGIUM
------------------------------------------------------------------
Comment 2 Martin Kiehne 2002-07-31 13:29:16 UTC
Hi Michael

thanks for replying so soon and sorry for me being a little bit late.

> I can try to find a better solution but first of all I need at least
> to reproduce it which I can't. How did you disable the classes? I
> tried locally by adding:
>
> <Location /classes>
> Order DenyAllow
> Deny From All
> </Location>
This is exactly what is causing the effect for us.
I suppose you tried accessing /classes/ via a web browser and got 
403 Forbidden?

Here's a dump of the communication between kprinter and our cups server (I 
removed the content data because it contains non-printable characters except 
for the last reply):
===========================================================
POST /printers/ HTTP/1.1
Content-Length: 224
Content-Type: application/ipp
Host: localhost

[data...]
-----------------------------------------------------------
HTTP/1.1 200 OK
Date: Wed 31 Jul 2002 12:56:31 GMT
Server: CUPS/1.1
Connection: Keep-Alive
Keep-Alive: timeout=60
Content-Language: C
Content-Type: application/ipp; charset=iso-8859-1
Content-Length: 4795

[data...]
-----------------------------------------------------------
POST /classes/ HTTP/1.1
Content-Length: 224
Content-Type: application/ipp
Host: localhost

[data...]
-----------------------------------------------------------
HTTP/1.1 403 Forbidden
Date: Wed 31 Jul 2002 12:56:31 GMT
Server: CUPS/1.1
Content-Language: C
Upgrade: TLS/1.0HTTP/1.1
Connection: close
Content-Type: text/html
Content-Length: 150

<HTML><HEAD><TITLE>403 Forbidden</TITLE></HEAD><BODY><H1>Forbidden</H1>You 
don't have permission to access the resource on this server.
===========================================================

Note:
"Host: localhost" in the POST request is not quite true though. In order to 
capture the communication I hacked jumpgate to dump the traffic while 
forwarding it from localhost to our server and directed kprinter to the 
localhost. Anyway the behaviour of kprinter is the same as if it connects 
directly to the server so I think it doesn't do any harm.

Hope this helps.

Thanks
Martin
Comment 3 Kurt Pfeifle 2007-01-13 04:27:59 UTC
WORKSFORME and timeout....
Comment 4 John Layt 2008-12-31 12:13:12 UTC
Closing old Resolved status bug.