Skip to content
Snippets Groups Projects
  1. Jul 17, 2024
  2. Jan 28, 2024
    • Marc Troelitzsch's avatar
      Remove some Python 2.x leftovers · 3f857829
      Marc Troelitzsch authored
      * `Iterator.next()`` has been replaced with `Iterator.__next__()`
      * The `object.__unicode__()` method is not used anymore
      * Default source encoding has changed from ASCII to UTF-8
      3f857829
    • Adam Williamson's avatar
      HTTP basic auth: encode username and password as UTF-8 (#315) · a96baa9e
      Adam Williamson authored
      As discussed upstream in
      https://github.com/psf/requests/issues/4564
      
       , HTTP basic auth
      usernames and passwords sent to requests as Python text strings
      are encoded as latin1. This of course makes it impossible to
      log in with a username or password containing characters not
      represented in latin1, as the reporter of #315 found out.
      
      To work around this rather old-fashioned default, let's intercept
      string usernames and passwords and encode them as utf-8 before
      sending them to requests.
      
      Anyone dealing with a really old server that can't handle utf-8,
      or something like that, can encode the username and password
      appropriately and provide them as bytestrings.
      
      Signed-off-by: default avatarAdam Williamson <awilliam@redhat.com>
      a96baa9e
  3. Jan 27, 2024
  4. Feb 25, 2023
    • Marc Troelitzsch's avatar
      #266: Add new Site.patrol function · 9359fd69
      Marc Troelitzsch authored
      9359fd69
    • Adam Williamson's avatar
      API calls: raise original exception when retries exhausted · 30b43690
      Adam Williamson authored
      
      This is an alternative approach to solve the problem identified
      in #279 . When doing API calls with `retry_on_error` set to
      true (the default), if the call fails after all retries are
      exhausted, we raise our own `MaximumRetriesExceeded` exception,
      which tells you nothing about what actually went wrong, just
      that we exhausted the retry count. It seems much more useful
      to raise an exception with information about why the connection
      is failing.
      
      This changes that behaviour so that, on most paths, we would
      raise an appropriate exception from requests (either the one
      we caught, or an HTTPError via `raise_for_status`) if we exhaust
      the retry count. Only if we fail due to database lag would we
      still raise `MaximumRetriesExceeded` (because there isn't really
      an underlying exception we can handily raise in that case).
      
      Note that it was already possible to hit
      `stream.raise_for_status()` before this change, if the status
      code was outside the 500 range, so in theory callers should
      already be prepared for that. It was not possible to get a
      `requests.exceptions.ConnectionError` or
      `requests.exceptions.Timeout` with `retry_on_error` true, though,
      so this is genuinely a behaviour change on that front.
      
      Signed-off-by: default avatarAdam Williamson <awilliam@redhat.com>
      30b43690
  5. Feb 19, 2023
    • Adam Williamson's avatar
      Handle page protection having no expiry (#290) · 44e6066f
      Adam Williamson authored
      
      Issue #290 gives an example of a wiki with protected pages whose
      protection definitions have no 'expiry' key at all. This seems
      strange and, on a quick through the mediawiki code, difficult
      to achieve, but since there's a live site out there that does it,
      and mediawiki *does* seem to have at least some code to handle
      such cases (e.g. how the expiry shows as 'indefinite' in the
      page information), let's handle it too, by representing this as
      None.
      
      Signed-off-by: default avatarAdam Williamson <awilliam@redhat.com>
      44e6066f
  6. Feb 10, 2023
  7. Sep 22, 2021
  8. May 28, 2020
  9. Oct 10, 2019
  10. Aug 02, 2019
  11. Feb 17, 2019
  12. Nov 04, 2018
  13. Jun 28, 2018
  14. Jan 14, 2018
  15. Jan 11, 2018
Loading