Add an asynchronous aiohttp Redfish client

[jyundt]

Summary

Add a separate asynchronous Redfish client implemented with aiohttp while leaving the existing synchronous API unchanged.

The new redfish.aio package supports caller-owned sessions, HTTP Basic authentication, cached responses, configurable timeouts, same-origin URL validation, and standard ComputerSystem discovery and reset operations.

Closes #189.

Motivation

Asyncio applications need nonblocking Redfish communication without maintaining a separate protocol implementation. In particular, Home Assistant requires integrations to use its shared aiohttp.ClientSession so connection pooling, TLS configuration, proxy behavior, and session lifecycle remain under application control.

This work supports the generic Redfish integration proposed in home-assistant/core#177991.

Implementation

The asynchronous API:

• Requires a caller-provided aiohttp.ClientSession.
• Never creates or closes the caller's session.
• Provides coroutine-based get, head, post, put, patch, and delete methods.
• Supports HTTP Basic authentication.
• Supports default and per-request timeouts.
• Fully reads and caches responses before returning them.
• Does not follow redirects.
• Accepts relative, scheme-relative, and absolute advertised targets only when they resolve to the configured Redfish origin.
• Treats implicit and explicit default ports as the same origin.
• Prevents custom headers from replacing or duplicating the configured Basic authentication header.
• Translates connection, timeout, authentication, HTTP, protocol, invalid-target, and unsupported-reset failures into dedicated exceptions.
• Is available through the optional redfish[aiohttp] dependency.

The standard ComputerSystem support:

• Starts from /redfish/v1/.
• Follows the advertised Systems collection link.
• Follows paginated Members@odata.nextLink links while rejecting pagination cycles.
• Retrieves individual ComputerSystem resources.
• Preserves standard identity, metadata, and exact PowerState values.
• Reads reset types advertised inline and through standard ActionInfo resources.
• Filters reset capabilities to standard Redfish reset types.
• Uses the reset-action target advertised by the service.
• Rejects reset types that the service did not advertise.
• Sends reset requests as {"ResetType": "<advertised type>"} without constructing vendor-specific action paths.
• Applies a configurable deadline to the complete discovery operation.

Documentation and an asynchronous discovery example are included.

Backward compatibility

The existing synchronous client and public API are unchanged. aiohttp is optional and is not installed unless the aiohttp extra is selected.

A base-wheel installation was verified to import successfully without aiohttp installed.

Validation

• Python 3.8: 40 tests passed.
• Python 3.11: 40 tests passed.
• Python 3.12: 40 tests passed.
• Python 3.13: 40 tests passed.
• Python 3.14: 40 tests passed.
• Async package coverage: 100% across 250 statements.
• Declared minimum aiohttp==3.9.0: 29 async tests passed on Python 3.8.
• New async source, tests, and example pass Flake8.
• Source distribution and wheel build successfully.
• Both artifacts pass twine check.
• Wheel installation with redfish[aiohttp] exposes the complete async API.
• The commit includes the required DCO sign-off.

Live validation

The built wheel was validated against a physical Redfish BMC using a caller-owned ClientSession with certificate fingerprint verification.

The validation successfully retrieved the service root, discovered a ComputerSystem, read its metadata and reported PowerState, followed its standard ActionInfo resource, and parsed its advertised reset types and reset target.

The network trace contained exactly five requests, all of which were GET. No reset or power-control action was issued.