A clear and concise description of what the problem is. For example, "I'm always frustrated when..."
arXiv (sometimes?) includes a valid Atom feed explaining non-200 responses. For example, see #74.
Solution
A clear and concise description of what you want to happen.
_parse_feed should make a best-effort at parsing the response body when it's about to raise an HTTPError.
If it's available, include that response body in the HTTPError and in that error's representations.
Considered alternatives
A clear and concise description of any alternative solutions or features you've considered.
N/A
Additional context
Add any other context about the feature request here.
There's an open question: if a body is available, and it's a valid feed, what should we do with it?
Include it as a string; don't bother to parse the XML. Let the user determine how best to do that.
Include it as a feedparser object.
Parse with feedparser, but process the feed entries into differentiated errors.
I suspect the right approach is to begin with 1––just to start representing the dropped context to users––and then move on to step 3 if there are requests to differentiate HTTP errors programmatically.
Motivation
arXiv (sometimes?) includes a valid Atom feed explaining non-200 responses. For example, see #74.
Solution
_parse_feedshould make a best-effort at parsing the response body when it's about to raise anHTTPError.If it's available, include that response body in the
HTTPErrorand in that error's representations.Considered alternatives
N/A
Additional context
There's an open question: if a body is available, and it's a valid feed, what should we do with it?
feedparserobject.feedparser, but process the feed entries into differentiated errors.I suspect the right approach is to begin with 1––just to start representing the dropped context to users––and then move on to step 3 if there are requests to differentiate HTTP errors programmatically.