The issue with the IOException constructor is fixed in this revised patch.
At first, implementing Felix's other suggestions seemed easy, but proved more complicated:
>> Now, sling.servlets.post does not have a dependency to Engine. Do we want to introduce that? Or move RequestUtil to API?
> Right. Yes, moving RequestUtil to API might make sense, on the other hand, we should probably not add more real classes to the API module. Rather I was thinking of (yet another ?) commons module.
I suggest we create a separate task for this. Once we have RequestUtil in a separate bundle, that sling.servlet.post can depend on, we'll remove MediaRangeList and use RequestUtil.parseAcceptHeader.
>> This could probably be easily rewritten to use HtmlResponse's hashmap, and populating the JSONObject on send().
> I would prefer that even though it might seem a bit more expensive. The main reason for me would be simplicity: You just have to overwrite a single method - the rendering method - and otherwise have the exact same implementation. For output JsonWriter could then be used instead of JSONObject.
The problem is that HtmlResponse does not have a getProperties() method - only getProperty() methods to retrieve named properties.
So that leaves me with two options: Either a) record keys of all properties that are changed in a set in JsonResponse, so we'll know which properties to get from HtmlResponse on send(). This kind of invalidates the simplicity argument
or b) implement a HtmlResponse.getProperties() method. Since HtmlResponse is in sling.api, this would mean that the dependency to API would have to be updated to 2.0.9-SNAPSHOT.
I'm inclined to leaving this as it is for the moment, so that this issue can be resolved with changes to no other bundles than sling.servlet.post. Which again means that we're not holding back a release of sling.servlet.post by introducing this feature.