Right now, the Request and Response objects handle the body, this is fine but makes it hard to standardize this stuff, plus I'm not wild that Request has .body and .body_kwargs while Response has ._body and .body. And one final thing, while we support json we don't do a good job of explicitly handling other content types or erroring out when we don't recognize how to handle the content type.
This is my proposal to clean all the above up:
Request body should be completely read in at the start of the request, we used to do this, then we didn't, but I can't find in the commit logs our reasoning for why we changed to being read on demand, but I think we should go back to reading it in right at the beginning.
There should be a create_request_body method added to the Server class, this can be called from Server.create_request method when it is decided that a body is present.
There should be a create_response_body method added to the Server class, for uwsgi, this can be called in the Application.__call__ method, basically that method should now return whatever is returned from this method, it can handle making sure the Response body is properly formatted, so for uwsgi it would make sure an iterator is returned, but for websockets it can be responsible a payload is returned (really, the addition of these 2 methods might make it so Payload can be removed).
Both objects should have a ._body which is the completely raw body, a .body which is the formatted body, and .body_kwargs which is .body formatted as a dict in some form (not quite sure on this whole thing).
I think implementing the above will make it easier to override the request/response pipeline for new formats (like xml or something) and clean up a bunch of legacy hacks that have built up through the years.
Right now, the Request and Response objects handle the body, this is fine but makes it hard to standardize this stuff, plus I'm not wild that Request has
.bodyand.body_kwargswhile Response has._bodyand.body. And one final thing, while we support json we don't do a good job of explicitly handling other content types or erroring out when we don't recognize how to handle the content type.This is my proposal to clean all the above up:
Request body should be completely read in at the start of the request, we used to do this, then we didn't, but I can't find in the commit logs our reasoning for why we changed to being read on demand, but I think we should go back to reading it in right at the beginning.
There should be a
create_request_bodymethod added to the Server class, this can be called fromServer.create_requestmethod when it is decided that a body is present.There should be a
create_response_bodymethod added to the Server class, for uwsgi, this can be called in theApplication.__call__method, basically that method should now return whatever is returned from this method, it can handle making sure the Response body is properly formatted, so for uwsgi it would make sure an iterator is returned, but for websockets it can be responsible a payload is returned (really, the addition of these 2 methods might make it so Payload can be removed).Both objects should have a
._bodywhich is the completely raw body, a.bodywhich is the formatted body, and.body_kwargswhich is.bodyformatted as a dict in some form (not quite sure on this whole thing).I think implementing the above will make it easier to override the request/response pipeline for new formats (like xml or something) and clean up a bunch of legacy hacks that have built up through the years.