almarklein / asgineer Goto Github PK

The tests work fine on Windows, but on Linux (and CI) they do not. I've spend nearly as much time on this than the lib itself :(

It looks like Starlette's middleware that is designed to be framework agnostic. It would be interesting to see if we can fit that in Asgish somehow. Perhaps @tomchristie has some remarks/tips?

I intend to keep Asgish as simple as possible, but some tasks are common and can be abstracted as a utility. I am not sure whether I'd add any, but I might, e.g. when I find myself writing a certain piece of code in multiple places.

Examples:

• Routing
• Compression
• Request caching headers

I find that name rather ugly. Though it's explicit and clear...

Options:

• Keep as is: clear but ugly
• handler_to_asgi: possibly more ugly
• application :/
• make_asgi / to_asgi
• ...

There's a problem here:

Take a look at this example:

$ curl -I -H "If-None-Match: 512dc2f89fea2c3794631fddb080e9db842542b0204cd3e2b13d1685d9f2a349" "http://localhost:5555/timetagger/"

HTTP/1.1 304 Not Modified
date: Wed, 28 Feb 2024 20:18:06 GMT
server: uvicorn
etag: 512dc2f89fea2c3794631fddb080e9db842542b0204cd3e2b13d1685d9f2a349
cache-control: public, must-revalidate, max-age=0
content-type: application/octet-stream
content-length: 0

Note the content-type (application/octet-stream) and content-length (0).

Now take a look at the description of "304 Not Modified" on MDN:

The response must not contain a body and must include the headers that would have been sent in an equivalent 200 OK response: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

This error is causing a problem when a server is proxied behind Apache. I can explain the problem, but it's complicated and I'm not sure getting into the details will help. The short version, more or less, is that Apache appears to notice the discrepancy, and substitutes a 404 response.

Or does this happen at the socket level?

Following Asgish' minimalistics approach I like to use a standard exception type. I'd picked IOError but EOFError might make more sense.

The new work in #11 would make it possible to see coverage, lets go for that 100%

This would allow 3d party code that uses Asgish to hook up with Asgish better. And it is an extra validation step.

I'd like to do authorization in a websocket handler before accepting the connection. For example:

async def websocket_handler(request):
    if not is_authorized(request):
        return 401, {"WWW-Authenticate": "Basic"}, "Invalid credentials"

    await request.accept()

I expected it to send the HTTP response, but instead it raised the following exception:

OSError: A websocket handler should return None; use request.send() and request.receive() to communicate.

Let's start to check with how it would look, and see if it fits into the current approach.

See django/asgiref#69

Should this return request.headers['host'] if available? That one is probably more what the user needs than request.context.server[0]

The point of Asgish is to be tiny. From the start it did not have a Response class like most other web frameworks. Here I write down some thought about that...

Any HTTP response is really just a status code, headers, and a body. And the first two can be set to sensible defaults in many cases. I like the idea of being able to write an Asgish handler in a module that has zero imports; this is what gives it this ASGI-ish feel ...

One use-case where a response object might be convenient is when the request is delegated to another handler, and you want to inspect/tweak its response. Though in such a situation you can mandate to internally use the three-tuple (status, headers, body) explicitly.

I'd be happy to hear if I am overlooking something.

make_asset_handler() compresses all files above a certain size, including e.g. .png. Instead, it should only use the compressed version if it's 90% or less of the original.