Replies: 1 comment
|
Good question. Short answer: client settings like timeouts are not automatically forwarded to custom transports — this is by design. The Why this makes sense for your caseFor your SPARQL in-memory graph transport, timeouts don't really apply — querying an in-memory Graph object is synchronous and effectively instant. So not having timeout support is fine. However, if you wanted to respect client settings in a custom transport (e.g., for consistency or for transports that do actual I/O), here's how: Accessing client config in a custom transportThe import httpx
class GraphTransport(httpx.BaseTransport):
def __init__(self, graph):
self.graph = graph
def handle_request(self, request: httpx.Request) -> httpx.Response:
# Timeout is available in extensions (if you need it)
timeout = request.extensions.get("timeout", {})
# timeout is a dict like {"connect": 5.0, "read": 5.0, "write": 5.0, "pool": 5.0}
# Your in-memory query logic
result = self._query_graph(request)
return httpx.Response(200, content=result)So timeouts are passed through — you just need to check Other client settingsFor other settings like
So those settings do work with custom transports — only timeout enforcement is left to the transport implementation. Summary
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hello,
I have a question regarding the behavior of
httpx.Clientin the context of custom Transports (i.e.httpx.BaseTransportsubclasses).I am implementing a SPARQL Protocol client that, apart from targeting remote endpoints, also supports running queries against in-memory Graph objects. The Graph object feature is implemented using custom Transport classes that essentially delegate any SPARQL operation request to the given Graph object instead of a remote endpoint.
These are my current Transport definitions: https://github.com/lu-pl/sparqlx/blob/main/src/sparqlx/utils/transports.py
I just realized that for any
httpx.Clientinitialized with those Transports, client settings like e.g. timeouts are not recognized. It seems likehttpx-defined transports like e.g.httpx.WSGITransportdo not recognize client settings either (as far as I can tell).So I am wondering: Are client configs even meaningful with custom transports? If yes, how to best implement client config recognition with custom transports?
Any help is much appreciated! :)
All reactions