-
-
Notifications
You must be signed in to change notification settings - Fork 948
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make content
argument required to JSONResponse
#1431
Make content
argument required to JSONResponse
#1431
Conversation
Remove count of available convertors (#1409) Co-authored-by: Micheal Gendy <[email protected]> Fix md5_hexdigest wrapper on FIPS enabled systems (#1410) * Fix md5_hexdigest wrapper on FIPS enabled systems * Update _compat.py * lint Use typing `NoReturn` (#1412) change github issues template Sort third-party packages and add `starlette-wtf` (#1415) Improvements on authentication documentation (#1420) * Use `conn` in `AuthenticationBackend` documentation * Remove unused import in `AuthenticationBackend` documentation * Add missing imports in authentication documentation Co-authored-by: Marcelo Trylesinski <[email protected]> Add third-party CSRF middlewares (#1414) * change github issues template * Add third-party CSRF middlewares Co-authored-by: Tom Christie <[email protected]> Allow Environment options in `Jinja2Templates` (#1401) Adjust type of `exception_handlers` to allow async callable (#1423) Default WebSocket accept message headers to an empty list (#1422) * If no extra headers are passed, set it to an empty list * Test websocket.accept() with no additional headers * Update starlette/websockets.py Co-authored-by: Marcelo Trylesinski <[email protected]> * Update tests/test_websockets.py Co-authored-by: Amin Alaee <[email protected]> * Update tests/test_websockets.py Co-authored-by: Marcelo Trylesinski <[email protected]> Co-authored-by: Marcelo Trylesinski <[email protected]> Co-authored-by: Amin Alaee <[email protected]> Add reason to WebSocket closure (#1417) Co-authored-by: Marcelo Trylesinski <[email protected]> Version 0.18.0 (#1380) * Version 0.18.0 * Add changes until 14 jan * Update release-notes.md * Update release-notes.md * Update release-notes.md * Update release-notes.md Co-authored-by: Adrian Garcia Badaracco <[email protected]> Co-authored-by: Amin Alaee <[email protected]> draft Update publish.yml (#1430)
Okay - neat starting point. We'll need to expand on the actual motivation here, and the desired behavioural changes, but lemme first jump in with some review points. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so my expectations around the changes we'd want to see are:
- The status code becomes "defaults to either 200 or 204" rather than "defaults to 200".
- Omitting the
content
or passingcontent=None
defaults to "don't render anything, body isb''
" rather than "renderNone
and return that as the body".
We've probably also got a follow up tweak that we'd want to not set any content-type in that case, but let's take this step by step.
Okay, see whatcya think about that. |
What about 307? |
|
@Kludex I think the |
Co-authored-by: Tom Christie <[email protected]>
Co-authored-by: Tom Christie <[email protected]>
Co-authored-by: Tom Christie <[email protected]>
Co-authored-by: Tom Christie <[email protected]>
Co-authored-by: Tom Christie <[email protected]>
This makes sense now. Thank you for the feedback. I'll take a look at the tests later today. |
hi guys, maybe You should consider my point of view: from my expierence 204 should also be used in cases when request was process successfully on some entity. It's inform that it was process and do not need to reload or something (look link above) 200 is more general, more intuitive, for empty responses it's like standard. It is also good when default status code will remain same, not to create confusion for someone new :). I think it's good idea to stay with is there is not content body should be b''. Let me now, what You guys think |
@aminalaee a humbly remind to add the motivation of this PR on the description 🙏 |
Response
default status_code
to 200 or 204 depending on content
Response
default status_code
to 200 or 204 depending on contentResponse
default status_code
to 200 or 204 depending on content
Flask's |
Hrm. I'm just not sure here. We're actually bundling up two different but related concerns...
It's possible we should consider those separately. I'm maybe not that fussed about (2) - it probably ends up being slightly unexpected for some users. However (1) probably? sounds like a good idea. Practically the behavioural change it makes within Starlette itself is only for the Having said that, we'd also want to adapt Forgetting about (2) for now, I think options are...
After reading that through, I think the last one is a pretty neat plan. Eg...
I quite like that approach overall. Doesn't allow me to do things that's ambiguous. Has the behaviour I'd expect in all other cases. It's a breaking change, but it's only a breaking change for users doing something a bit wrong and marginally broken. We'd describe it to users in this way...
|
…inalaee/starlette into modify-response-class-and-status-code
Response
default status_code
to 200 or 204 depending on contentcontent
argument required to JSONResponse
This seems better to me, right? Also - I don't think we really need to deal with auto-defaulting 204 for This change on it's own is actually a neat enough bit of guard-railing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes a lot of sense to me, yup.
Making
content
argument required inJSONResponse
:Response
will work as before defaulting tob""
whencontent
isNone
JSONResponse()
will fail ascontent
is requiredJSONResponse({})
will work as expectedJSONResponse(None)
will be rendered asnull