Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support parameters for custom media types #2005
When a custom media type is matched we now add parameters. In particular this now means that users can support the
This change will be used downstream in Play's Akka HTTP backend. Play will be able to override the
Thank you for your pull request! After a quick sanity check one of the team will reply with 'OK TO TEST' to kick off our automated validation on Jenkins. This compiles the project, runs the tests, and checks for things like binary compatibility and source code formatting. When two team members have also manually reviewed and (perhaps after asking for some amendments) accepted your contribution, it should be good to be merged.
For more details about our contributing process, check out CONTRIBUTING.md - and feel free to ask!
referenced this pull request
May 2, 2018
Unless I'm misreading this dropping
areNoCustomMediaTypesDefined means we're now slower in that case, so perhaps it would be good to bring that back?
Regarding the main change, I'm inclined to be OK with it - the 'strange' corner case is a case where there's nothing more sensible we can do (beyond rejecting the request) anyway. Would appreciate another careful review though :).
According to the comment in the previous code the goal was to eliminate the allocation of a closure. The new code still avoids creating a closure. The previous code avoided the closure by comparing on the function to see if it was known to be a nop. The new code avoid the closure by comparing on the result of the function. In the common case calling the function and comparing the result will be fast.
Does that sound right? If so I think it should be about the same speed - one function call and one (reference?) equality check in either case?
IMO the new code seems like a cleaner way to do that, since it doesn't require extra methods across several different source files. The new code will also be faster when their is a custom media type defined but the function returns
That does sound a bit odd. What I've done here is made custom media types behave the same way as predefined ones. What happens in the existing code when a predefined
I probably should have mentioned that this was the approach that I worked out with @jrudolph - at least according to the old notes and code I left in the description of playframework/playframework#8239.
It's not obvious to me whether the
I think I'd feel more confident about the consequences of the removed
But as usual gut feeling is worth close to 0 with performance things, benching is the only thing we can trust.
Except for that I think the change looks fine.
Looking a bit closer now in the common no-custom-types case
May 15, 2018
Hi, can we please get a backport of this to Akka HTTP 10.0.x so that we can support it in the stable 2.6.x branch of Play? That will let us fix this issue: playframework/playframework#8239
(Also do you want to tag this PR with play-akka-http-integration?)