bad error handling when a project is not found

Bug #440023 reported by Edwin Grubbs on 2009-10-01
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

If you try to look up a non-existent project with lplib.projects[project_name], it will normally raise a KeyError except when the project_name starts with a space. In that case, it returns a bogus Entry object. Oddly, displays a NotFound exception, but, which launchpadlib uses, returns the bogus Entry object.

Here is how you can recreate the problem with launchpadlib/contrib/

$ ~/work/trunk/bin/py
>>> lp = lp_factory('edge')
Loading credentials...
>>> project = lp.projects[' foo']
>>> type(project)
<class 'lazr.restfulclient.resource.Entry'>
>>> project.lp_attributes
>>> project.lp_collections
['cves', 'branches', 'packagesets', 'distributions', 'projects', 'project_groups', 'translation_import_queue_entries', 'people', 'bugs']
>>> project.lp_entries
['me', 'pillars']
>>> print project
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/egrubbs/canonical/lp-sourcedeps/eggs/lazr.restfulclient-0.9.5-py2.4.egg/lazr/restfulclient/", line 564, in __str__
    return self.self_link
  File "/home/egrubbs/canonical/lp-sourcedeps/eggs/lazr.restfulclient-0.9.5-py2.4.egg/lazr/restfulclient/", line 571, in __getattr__
    return super(Entry, self).__getattr__(name)
  File "/home/egrubbs/canonical/lp-sourcedeps/eggs/lazr.restfulclient-0.9.5-py2.4.egg/lazr/restfulclient/", line 308, in __getattr__
    raise AttributeError("'%s' object has no attribute '%s'"
AttributeError: 'Entry' object has no attribute 'self_link'

Here is the actual web request that launchpadlib is making. It appears that this is an error in lazr.restful.

> /home/egrubbs/canonical/lp-sourcedeps/eggs/lazr.restfulclient-0.9.5-py2.4.egg/lazr/restfulclient/
-> response, content = self._request(url, extra_headers=headers)
(Pdb) url
' foo'
(Pdb) response
{'status': '200', 'content-length': '913', 'via': '1.0', 'content-location': ' foo', 'x-powered-by': 'Zope (, Python (', 'vary': 'Cookie,Authorization,Accept', 'server': 'zope.server.http (HTTP)', 'connection': 'close', 'etag': '"bf97412f779135f204f5df44d1e7f65b2e4bb44a"', 'date': 'Thu, 01 Oct 2009 14:21:27 GMT', 'content-type': 'application/json'}
(Pdb) content
'{"me_link": "", "cves_collection_link": "", "branches_collection_link": "", "packagesets_collection_link": "", "distributions_collection_link": "", "projects_collection_link": "", "project_groups_collection_link": "", "translation_import_queue_entries_collection_link": "", "pillars_link": "", "bugs_collection_link": "", "resource_type_link": "", "people_collection_link": ""}'

Revision history for this message
Leonard Richardson (leonardr) wrote :

lazr.restfulclient should URL-escape the names when it does lookups. This is just one instance of a general problem.

This isn't a very serious bug, and since bad code now results in an error rather than silent weirdness (albeit not a very helpful error), I think it's less serious still.

Changed in lazr.restful:
status: New → Triaged
importance: Undecided → Low
affects: lazr.restful → lazr.restfulclient
Revision history for this message
Leonard Richardson (leonardr) wrote :

For the record, the reason this isn't a bug in lazr.restful is that "GET /foo bar HTTP/1.1" is an invalid HTTP request. It's legal to interpret this as "GET /foo HTTP/1.1", which is what lazr.restful (actually Zope, I suspect) is doing.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers