Repository navigation
Make invoking "response.raise_for_status()" optional #36
Description
Activity
I can give a real life example where this can be unexpected. OPS returns
413 Request Entity Too Large(https://http.dev/413) which is their way of telling you that the request input was ambiguous:
1 CLIENT.AmbiguousRequest may happen only when requesting the information in DOCDB format. For example the request http://ops.epo.org/rest-services/published-data/publication/epodoc/EP.0536425/fulltext will always return the claims/description availability for the given number while http://ops.epo.org/rest-services/published-data/publication/docdb/EP.0536425/fulltext will result ambiguity, as given number matches several publications. The client needs to select some number and repeat the request using that specific number.
GET http://ops.epo.org/rest-services/published-data/publication/docdb/EP.0536425/fulltextwill return:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <fault xmlns="http://ops.epo.org"> <code>CLIENT.AmbiguousRequest</code> <message>The request was ambiguous</message> <details> <cause>Ambiguous input: publication/docdb/EP.0536425</cause> <resolution>publication/docdb/EP.0536425.A1</resolution> <resolution>publication/docdb/EP.0536425.A4</resolution> <resolution>publication/docdb/EP.0536425.B1</resolution> <resolution>publication/docdb/EP.0536425.B2</resolution> </details> </fault>
As you can see, the response actually contains helpful information which one could present to the user or the caller. This currently results in an exception being thrown.
Side note: Status code 300 would have been a better choice here, but what are the chances that the EPO would make a change like that 😄
Hi @ofipify,
thank you for replying to this issue.
As you can see, the response actually contains helpful information which one could present to the user or the caller.
I figure you are confirming what we said the other day?
For reasons I am currently not able to remember exactly, we wanted to turn that behavior off within PatZilla. Most probably it was because the exception bubbling up from this method lacked important information from the original request object we wanted to present to the user, like details from OAuth failures or rate limiting errors we are extracting from HTTP response headers or similar things.
So, would you also prefer that
response.raise_for_status()is not invoked by default?With kind regards,
Andreas.- linked a pull request that will close this issueMake raise_for_status configurable #159
on May 16, 2026
Hi there,
coming here from #35 (comment), @gsong was so kind to offer he would think about an option on how to toggle the behavior of one of the core methods within this library.
We are talking about the
_make_requestmethod here, which invokesresponse.raise_for_status()in order to raise exceptions on all HTTP requests to the OPS API which respond with HTTP status >= 400.For reasons I am currently not able to remember exactly, we wanted to turn that behavior off within PatZilla.
Most probably it was because the exception bubbling up from this method lacked important information from the original request object we wanted to present to the user, like details from OAuth failures or rate limiting errors we are extracting from HTTP response headers or similar things.
Please advise if we are getting this wrong and the same things could be achieved with this call in place. Thanks!
With kind regards,
Andreas.