Request data extractors to allow posting other formats than JSON #192
Conversation
ghost
mentioned this pull request
|
Argh, test failures with Py3. Will look into it. |
|
And here is the doc update :) What do you think? BTW I had to comment-out the mozilla theme in |
| @@ -478,6 +478,10 @@ def wrapper(request): | |||
| if is_string(view): | |||
| view_ = getattr(ob, view.lower()) | |||
|
|
|||
| # set data extractor | |||
| if 'request_data_extractor' in args: | |||
There was a problem hiding this comment.
What happens if it's not there? Shouldn't we fallback to a default value here?
There was a problem hiding this comment.
This is for the view config parameter. If it's not there we fallback to the global dictionary keyed by content-type, which is populated with json and form-urlencoded decoders when when the app start.
|
I added a few comments here and there, thanks for the work. About the sphinx theme, I'm fixing this right now :-) |
|
Ready to be merged? Can you squash these commits into one and add an item in the changelog? |
* add built-in support for www-form-urlencoded data (ie. traditional HTML form submission) * allow specifying custom deserializers for other input types through app configuration or view configuration Includes work by Alexandre Bourget aka @abourget
|
There you go. |
|
great, thanks! |
Request data extractors to allow posting other formats than JSON
| requested content type asked by the client sending an ``Accept`` header. | ||
| Otherwise it will croak with a ``406 Not Acceptable``. | ||
|
|
||
|
|
There was a problem hiding this comment.
Hi Alex, Hi Alexis,
i added/rephrased this section in the documentation with PR #91 resolving issue #57. I believe this is still valid, since it's about "Content-Type" header validation, which happens before request body deserializing and is technically also completely independent from it.
Especially the constraints on the "Accept" http request header have nothing to do with the ingress request body, but rather with the egress response body.
Maybe we should rephrase the introductional sentence again, so instead of having:
Content validation
There are two flavors of content validations cornice can apply to services:
this could make it more clear:
Content-Type- and Accept-header validation
There are two flavors of constraints cornice can apply to http request headers:
What do you think?
Cheers,
Andreas.
|
Hi again, apparently this is still in master, i was mislead by the diff. Sorry for interrupting! |
Ref. #186
Creating a PR so it can be easily reviewed. It's not quite ready yet because I haven't updated the docs.
Also I'm not happy with the name 'request_data_extractor', but couldn't think of anything better so far.