Bug 676596
Summary: | [RFE] use reason phrase from HTTP status line in error messages | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Petr Šplíchal <psplicha> |
Component: | curl | Assignee: | Kamil Dudka <kdudka> |
Status: | CLOSED ERRATA | QA Contact: | Jiri Jaburek <jjaburek> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.1 | CC: | ddumas, jjaburek, jsynacek, ohudlick, ovasik, pknirsch |
Target Milestone: | rc | Keywords: | FutureFeature, Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | curl-7.19.7-30.el6 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-02-21 10:09:04 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 840699 |
Description
Petr Šplíchal
2011-02-10 10:27:59 UTC
The different error format also causes the upstream test suite to fail in the test_failure_callback subtest: =============================================================================== FAIL: test that MG executes the failure callback correctly ------------------------------------------------------------------------------- Traceback (most recent call last): File "test_mirror.py", line 120, in test_failure_callback '[Errno 14] HTTP Error 403') File "/tmp/tmp.p1OZ1Hz6jK/BUILD/urlgrabber-3.9.1/test/munittest.py", line 397, in failUnlessEqual (msg or '%s != %s' % (`first`, `second`)) AssertionError: '[Errno 14] PYCURL ERROR 2' != '[Errno 14] HTTP Error 403' The test case should be adjusted to match the actual expected format. The testcases failing is known. For the bug, do you have the fix for: 565654 ... also what is this a regression from, 6.0?? > For the bug, do you have the fix for: 565654 Yes, and the fix has already been verified: https://bugzilla.redhat.com/show_bug.cgi?id=565654#c14 > ... also what is this a regression from, 6.0?? Against RHEL5. This is basically the same bug as 565646, and it's already fixed for the same reasons ... if I run yum with a bad URL on 6.1 I get what you'd expect. *** This bug has been marked as a duplicate of bug 565646 *** Does not seem to be fixed. What I get is still just an error
number. I've tested python-urlgrabber-3.9.1-8.el6.noarch with the
following results:
> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> :: [ LOG ] :: http without credentials
> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>
> Traceback (most recent call last):
> File "./grab.py", line 9, in <module>
> urlgrab(url, filename)
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 618, in urlgrab
> return default_grabber.urlgrab(url, filename, **kwargs)
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 985, in urlgrab
> return self._retry(opts, retryfunc, url, filename)
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 886, in _retry
> r = apply(func, (opts,) + args, {})
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 971, in retryfunc
> fo = PyCurlFileObject(url, filename, opts)
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 1066, in __init__
> self._do_open()
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 1360, in _do_open
> self._do_grab()
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 1490, in _do_grab
> self._do_perform()
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 1347, in _do_perform
> raise err
> urlgrabber.grabber.URLGrabError: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 401"
> :: [ PASS ] :: Running './grab.py 'http://localhost/grabber/' without.html'
> :: [ FAIL ] :: File 'output' should contain 'Authorization Required'
>
> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> :: [ LOG ] :: http with valid user, non-existent file
> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>
> Traceback (most recent call last):
> File "./grab.py", line 9, in <module>
> urlgrab(url, filename)
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 618, in urlgrab
> return default_grabber.urlgrab(url, filename, **kwargs)
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 985, in urlgrab
> return self._retry(opts, retryfunc, url, filename)
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 886, in _retry
> r = apply(func, (opts,) + args, {})
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 971, in retryfunc
> fo = PyCurlFileObject(url, filename, opts)
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 1066, in __init__
> self._do_open()
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 1360, in _do_open
> self._do_grab()
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 1490, in _do_grab
> self._do_perform()
> File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 1347, in _do_perform
> raise err
> urlgrabber.grabber.URLGrabError: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404"
> :: [ PASS ] :: Running './grab.py 'http://httptester:httppassword@localhost/grabber/missing.html' missing.html'
> :: [ FAIL ] :: File 'output' should contain 'Not Found'
(In reply to comment #7) > Does not seem to be fixed. What I get is still just an error > number. I've tested python-urlgrabber-3.9.1-8.el6.noarch with the > following results: For reference curl/pycurl version was: python-pycurl-7.19.0-8.el6.x86_64 curl-7.19.7-26.el6_1.1.x86_64 Ok, I see what you are saying now. You aren't complaining about no message, but about the fact the message isn't as nice. But that's out of ours hands. In RHEL-5 we get the error message from httplib/urllib2 ... which maps "404" into "Not found" etc. In RHEL-6 we get the error message from curl/pycurl ... which just says "server responded 404". I have no problem with asking curl/pycurl to give better messages ... but I really don't want to parse the error message in urlgrabber and then rewrite it to be better. I see, thanks for clarifying. Moving to python-pycurl (see comment #9). This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. (In reply to comment #11) > I see, thanks for clarifying. Moving to python-pycurl (see comment #9). I don't think this is a problem of python-pycurl. The patch from https://bugzilla.redhat.com/show_bug.cgi?id=565654 is already there in 6.3. And if this is not a bug of urlgrabber, there must be something wrong with curl. The python-pycurl in RHEL 6.3 and Fedora 17 have the same vanilla source. Fedora doesn't even have the patch mentioned in bug #565654. $ urlgrabber http://www.redhat.com/g Fedora 17: [Errno 14] HTTP Error 403 - Forbidden : http://www.redhat.com/g/ RHEL 6.3: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 403" Actually, is this even a bug? It only looks like a different message that is mapped to the specific error code. > Fedora 17: > [Errno 14] HTTP Error 403 - Forbidden : http://www.redhat.com/g/ > > RHEL 6.3: > [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 403" I am not aware of any change in libcurl that would cause the difference above. (In reply to comment #17) > Actually, is this even a bug? I would not say so. See RFC 2616, 6.1.1: "... The client is not required to examine or display the Reason-Phrase." Error messages are not meant to be stable among releases. Wherever compatibility matters, HTTP status codes should be used instead of the error messages. This is apparently not a regression in curl. I am marking the bug as future feature. proposed upstream: http://thread.gmane.org/gmane.comp.web.curl.library/36393 upstream commit: https://github.com/bagder/curl/commit/d317ca5 fixed in curl-7.26.0-6.fc18 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0393.html |