On Thu, 21 Nov 2019, at 09:25, Tom Forbes wrote: > > If Django were to provide a solid API for parsing Accept headers [not as > > easy as it sounds] and selecting a preferred response type [based on accept > > preference weights] ... would that take care of the bulk of "content > > negotiation”? > > > I could imagine a view progressing past the boiler plate [verifying the > > target object exists, etc], doing its "work", then checking what response > > form to use, and branching there. > > I had a look at how DRF handles parses Accept headers, and it honestly > doesn’t look too tricky: > https://github.com/encode/django-rest-framework/blob/39876e66070c1d6f97740789d5c6f6a0a3ea06cf/rest_framework/utils/mediatypes.py#L52-L62. > The precedence logic is a bit complex, but all in all it’s under ~30 lines > of actual implementation code.
Yeah, I expected DRF had this "solved" already. From my own experimentation, mapping `cgi.parse_header` over the the "Accept" header value, split by comma, gets a usable result; then sort that list by 'q' (defaulting to 1.0) and you have your priority. But knowing that's the right way to parse Accept headers, and asking for match or quality measures of your response options, feel like an abstraction Django could/should provide. > But providing the ability to parse accept headers and branch is simple enough > to match a lot of the current “is_ajax” usages without too many changes. I > don’t see much value in trying to tackle more complex/structured content > negotiation handing. This was my hope - an 80/20 solution that in no way precluded other solutions. -- C -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/519f9b4e-ad9d-4814-ad6f-c6faff809867%40www.fastmail.com.
