Intercepted errors should be returned as HTTP errors to the client

[simonw]

This code here:

asgi-proxy-lib/asgi_proxy/__init__.py

Lines 75 to 79 in 0730e87

	except Exception as e:
	# Handle any errors during the request
	if log:
	log.error(f"An error occurred: {e.__class__.__name__}: {e}")
	return

It should actually return a 500 error with a simple HTML page saying roughly what went wrong.

There are actually a few relevant HTTP errors here:

• 502 Bad Gateway - if it gets a "bad response" of some sort from the backend (not sure what the definition of "bad" there should be).
• 504 Gateway Timeout - if the backend times out. Having a timeout setting would be useful generally.
• 503 Service Unavailable - backend server is unavailable.

I'm not sure how to decide between a 502 and a 503.

[simonw]

503 sounds like it might be more of a deliberate thing for me - an error you serve if you have taken the backend down for maintenance.

[simonw]

So I think 404 / 500 / etc errors from the backend are proxied through exactly as they are received.

HTTP errors from httpx should turn into "502 Bad Gateway", maybe with extra information displayed derived from the exception.

There should be a timeout=x option which is passed to HTTPX and turns into a 504 if exceeded.

[simonw]

The main thing that try/except block is wrapping is

asgi-proxy-lib/asgi_proxy/__init__.py

Lines 36 to 38 in 0730e87

	async with client.stream(
	method, url, data=body or None, headers=headers
	) as resp:

Hard to tell exactly what exceptions it may need to deal with - relevant HTTPX code is at https://github.com/encode/httpx/blob/6a1841b924ab5d318d771e1a04ffb55662bf458b/httpx/_client.py#L844-L866 but it calls a lot of other methods.

HTTPX does have a well documented exception hierarchy on this page: https://www.python-httpx.org/exceptions/