BlackSheep does't work with a2wsgi

I attempted to use BlackSheep with https://github.com/abersheeran/a2wsgi so that I could use BlackSheep with https://pywebview.flowrl.com/ which expects a WSGI application.

It doesn’t work because it seems that BlackSheep does not fully conform to the ASGI specification. Specifically, the raw_path field in an ASGI connection scope is optional, but BlackSheep treats it as required. a2wsgi does not provide this field, so when running a BlackSheep app under its ASGIMiddleware, a KeyError is thrown at https://github.com/Neoteroi/BlackSheep/blob/main/blacksheep/server/application.py#L632

I thought this would be easy to fix myself, and started to attempt to, but then I ran across this block of code: https://github.com/Neoteroi/BlackSheep/blob/main/blacksheep/server/application.py#L682-L689 - it looks like MountMixin depends on raw_path being present, and I’m not sure if it would be correct to rewrite it to use path.

[jordemort]

@RobertoPrevato No need to apologize; spending time with your family is always the right choice! Thanks for looking into it - it looks like a WSGI specification thing, re: https://www.python.org/dev/peps/pep-0333/

Applications and middleware are forbidden from using HTTP/1.1 “hop-by-hop” features or headers, any equivalent features in HTTP/1.0, or any headers that would affect the persistence of the client’s connection to the web server. These features are the exclusive province of the actual web server, and a server or gateway should consider it a fatal error for an application to attempt sending them, and raise an error if they are supplied to start_response(). (For more specifics on “hop-by-hop” features and headers, please see the Other HTTP Features section below.)

[RobertoPrevato]

Thank You! 😄 I’m looking into this, I’m trying to disable the Transfer-Encoding header when serving files from the file system (obtaining the expected file size from os file information and assuming that the size is correct os.stat). I think that not all proxy servers follow the principle described in the WSGI specification, regarding hop-by-hop headers: for example I published blacksheep apps in Azure and they work well (they also run behind proxy servers there).

Async iterables returning bytes of arbitrary size wouldn’t be supported at that point, but it’s better than the current situation.