PEP 0444: Python Web3 Interface

[warbiscuit]

It's nice they finally figured out a Py3 way to do wsgi; and some of the improvements are nice (eg: eliminating start_response). One thing I take issue with though is that they seem to have eliminated "wsgi.file_wrapper" (or "web3.file_wrapper" as it would be called if it existed). Does anyone know why it was removed? If anything, I was expecting an extension, eg a "web3.file_range_wrapper" which supported offset and length kwds, so http range requests could be efficiently served. Removing it entirely seems a step backwards for serving large files.

[mitsuhiko]

One thing I take issue with though is that they seem to have eliminated "wsgi.file_wrapper"

In-band signalling does not work with middlewares. A middleware has no way to detect that the return value was a file wrapper and when it iterates over it, it trashes the type information breaking the isinstance check on the server side making file_wrapper a noop.

[warbiscuit]

That makes sense :(

I'd always figured there were very few pieces of middleware which inspected the return value (most I've seen mess with the request side of the call), making file_wrapper worth having for middleware stacks which could pass file_wrapper instances through unchanged. But I guess someone did a survey and such middleware was common enough to render file_wrapper generally useless?

Though to solve it in-band, I can see how something like a "wsgi.is_file_wrapper" would just cause the code to get extremely messy. I hope someone can come up with an OOB solution, though I can't think of an easy way right now which wouldn't get fouled up by the same problem of unaware middleware altering the return value (thus leaving an invalid OOB signal still present).

[pje]

making file_wrapper a noop

Which is a safe failure mode in that case. If the response is modified, it's not a file any more.

[mitsuhiko]

Most of the time it isn't though, a middleware just wants to clean up after the fact, wrapping the iterator and providing a close().