The Wayback Machine - https://web.archive.org/web/20200829130058/https://github.com/falconry/falcon/issues/1717
Skip to content
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

Custom media handlers: Unexpected issue when providing custom json handler #1717

Open
adsahay opened this issue Apr 22, 2020 · 9 comments
Open

Custom media handlers: Unexpected issue when providing custom json handler #1717

adsahay opened this issue Apr 22, 2020 · 9 comments

Comments

@adsahay
Copy link

@adsahay adsahay commented Apr 22, 2020

This is in falcon-2.0

Look at the documentation here for using rapidjson for encoding/decoding json. By providing:

extra_handlers={'application/json': json_handler} we are still left with the default handler for content-type application-json; charset=UTF-8. This results in an unexpected behaviour when some client library (e.g. Retrofit for Android) includes the charset in the header.

While the documentation should be updated, the expected behaviour is that if the handler for application/json is updated - it should also update the handler for variant with charset (or at least throw a warning) otherwise there is a possibility of hidden bugs.

@open-collective-bot
Copy link

@open-collective-bot open-collective-bot bot commented Apr 22, 2020

Hi 👋,

Thanks for using Falcon. The large amount of time and effort needed to
maintain the project and develop new features is not sustainable without
the generous financial support of community members like you.

Please consider helping us secure the future of the Falcon framework with a
one-time or recurring donation.

Thank you for your support!

@kgriffs kgriffs added this to the Version 3.0 milestone Apr 22, 2020
@kgriffs kgriffs added the bug label Apr 22, 2020
@kgriffs
Copy link
Member

@kgriffs kgriffs commented Apr 22, 2020

I agree we should make this better since it violates the principle of least-surprise. Scheduled for 3.0 in case someone wants to tackle it right away, otherwise it will need to be pushed to 3.1.

@vytas7
Copy link
Member

@vytas7 vytas7 commented Jul 4, 2020

FWIW, our media type negotiation machinery seems to automatically choose the application/json handler for requests sent as application-json; charset=UTF-8, even if an explicit handler for the latter is missing. In that light, could we just remove the explicit application-json; charset=UTF-8 handler from our codebase and the docs, now that we are defaulting to just application/json ourselves.

As a bonus, that would eliminate confusion in situations like @adsahay is describing.

I was testing the app below, and it seems to just work:

import falcon


class Resource:

    def on_post(self, req, resp):
        resp.media = req.get_media()


app = falcon.App()
app.req_options.media_handlers = falcon.media.Handlers({
    'application/json': falcon.media.JSONHandler(),
})
app.add_route('/mirror', Resource())

Thoughts?

@adsahay
Copy link
Author

@adsahay adsahay commented Jul 6, 2020

Yes this sounds great.

Also, it might be a stylistic preference, but in such situations if we can have a constant for all handlers (falcon.MIME_JSON) or something it will have the additional benefit of discoverability of available handlers in documentation / code completion, and avoid typos.

@adsahay
Copy link
Author

@adsahay adsahay commented Jul 6, 2020

If you want I can fix and send PR for this (my first falcon contribution!)

@vytas7
Copy link
Member

@vytas7 vytas7 commented Jul 6, 2020

Hi again @adsahay ,
We do have such constants (the stable version already has), maybe we just haven't updated all the docs with them yet. Or, we may have left explicit strings in selected places for clarity.

>>> import falcon
>>> falcon.MEDIA_JSON
'application/json'
>>> falcon.MEDIA_PNG
'image/png'
>>> falcon.MEDIA_TEXT
'text/plain; charset=utf-8'

@adsahay PRs are always welcome 🙂 👍
To be honest, I haven't fully explored the ramifications of removing the explicit UTF-8 JSON handler, it's just a quick idea that crossed my head. But maybe we could start a draft PR anyway?

@kgriffs thoughts on my suggestion to simplify the default JSON handlers by only keeping the application/json handler?

@kgriffs
Copy link
Member

@kgriffs kgriffs commented Jul 6, 2020

It could be that the key including the charset was left in to speed up the selection algorithm... regardless, I agree that it is not worth maintaining it since in most cases the charset will not be present in the string to begin with.

@vytas7
Copy link
Member

@vytas7 vytas7 commented Jul 18, 2020

@adsahay just checking, would you like to work on this by removing application-json; charset=UTF-8 from the default handlers?

As we proceed to remove it though, I would like to see a note added to the docs regarding speeding up the selection algorithm (needs to be verified with a benchmark!), as hinted by @kgriffs above. So that people could duplicate their handlers for a specific parameter set, if they expect that to be their common use case that needs to be optimized.

@adsahay
Copy link
Author

@adsahay adsahay commented Jul 21, 2020

Ok sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.