WSGI support is not spec conformant about granian HOT 8 CLOSED

No you shouldn't ignore the Content-Length header, if it is there you are supposed to use it. This is especially important for streaming larger respones where the iterable doesn't have a length of 1 (like in my example above). That said, my example is flawed since I do not implement support for len() at all -- that said I do not think that granian checks this anywhere currently.

My example about closing the connection was mostly about setting content length to 300 when the actual payload was "hello world" (ie shorter than 300). In this case the server has no good option but to close the connection since it would already have written "hello world" to the wire (in an ideal case) when it realizes that the rest of the data does not come.

from granian.

Using

def app(env, start_response):
    start_response('200 OK', [('Content-Type','text/html'), ('Content-Length', '300')])
    return Response([b"Hello", b" ", b"World"])

should not hang the server, from https://peps.python.org/pep-3333/#handling-the-content-length-header

Of course, if the application does not provide enough data to meet its stated Content-Length, the server should close the connection and log or otherwise report the error.

from granian.

start_response must return a write(body_data) callable, currently it returns None. Note that this mostly for older frameworks but the spec still requires it afaik.

start_response also need to support an optional exc_info

from granian.

If I am reading the code correctly, the whole response is also evaluated at once:

It would be better to write that back in a streaming fashion.

from granian.

Using

def app(env, start_response):
    start_response('200 OK', [('Content-Type','text/html'), ('Content-Length', '300')])
    return Response([b"Hello", b" ", b"World"])

should not hang the server, from https://peps.python.org/pep-3333/#handling-the-content-length-header

Of course, if the application does not provide enough data to meet its stated Content-Length, the server should close the connection and log or otherwise report the error.

https://peps.python.org/pep-3333/#handling-the-content-length-header also says

Under some circumstances, however, the server or gateway may be able to either generate a Content-Length header, or at least avoid the need to close the client connection. If the application does not call the write() callable, and returns an iterable whose len() is 1, then the server can automatically determine Content-Length by taking the length of the first bytestring yielded by the iterable.

So I think you can also ignore Content-Length and automatically determine Content-Length, instead of closing the connection (with is a more pleasing experience for everyone I think)

from granian.

No you shouldn't ignore the Content-Length header, if it is there you are supposed to use it. This is especially important for streaming larger respones where the iterable doesn't have a length of 1 (like in my example above). That said, my example is flawed since I do not implement support for len() at all -- that said I do not think that granian checks this anywhere currently.

My example about closing the connection was mostly about setting content length to 300 when the actual payload was "hello world" (ie shorter than 300). In this case the server has no good option but to close the connection since it would already have written "hello world" to the wire (in an ideal case) when it realizes that the rest of the data does not come.

You are right.

from granian.

The issue with closing the response iterator is now fixed, so I'm closing this.

In regards to supporting iteration over responses, you can open up a dedicated issue.

from granian.

from granian.