Add Content-Type response header to generated Resources

[Boerrild]

According to https://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1:

"Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body"

It further states that if not provided and if the client is unable to infer the type, it should be treated as "application/octet-stream" which will fail to correctly decode extended UTF characters. E.g. 'Å' becomes 'Ã�'. For that reason it is suggested that the generated resources adds the ResponseHeader.contentType("application/json; charset=utf-8") (or similar) header when constructing its responses.

[VaughnVernon]

@danilo-ambrosio Please test answering Completes<ObjectResponse<T>> from the request handlers. This should produce a Content-Type header that is compatible with the Request. Assuming this works we will need to find a way to use this in the code generation that isn't ugly. Perhaps we could create a method in Context to make it elegant.

[VaughnVernon]

@Boerrild May I ask what browser you are using, and how you are using the JSON entity? This has not been a problem before (not that our response absolutely correct) and I wonder if your aim is to render the JSON into the browser window rather than into a UI.

[Boerrild]

@VaughnVernon I've mainly been using Chrome (on Mac), but I also tried it on Safari and in addition I tried from a cURL-tool directly from IntelllyJ. In all three cases I saw the same result.

I'm building a Svelte/Sapper frontend (greatly inspired by your example project "vlingo-e2e-sys-airline-ops") rendering the JSON entities in the browser. Sapper uses a middleware-component, "polka", to routing requests to the backend vlingo-application. When the Content-type was missing from the responses, this component simply crashed, so it actually never reached the browser. Also, if I directed the request directly from the browser to the backend, the response still did not render the characters correctly.

[VaughnVernon]

@Boerrild Interesting. As you know we are doing what seems like the same thing Svelte+Sapper, not only in the example, but in all of our tool UIs. We have not experienced those problems. I wonder what gives. Anyway, we are fixing this in the Designer generator so it should be working correctly soon. Thanks for your patience. 😄

[VaughnVernon]

@Boerrild I am tempted to mark this fixed, but by now I am hesitant 😃 Please test and close if you agree.

See: https://github.com/vlingo/vlingo-http/commit/78776dbfa8d7dc00068e496c4e2e22f35249d0f3

https://github.com/vlingo/vlingo-xoom/commit/7ef3630f09539ad1a17c091fe4b4e21cbfa8c8cb

[Boerrild]

@Boerrild Interesting. As you know we are doing what seems like the same thing Svelte+Sapper, not only in the example, but in all of our tool UIs. We have not experienced those problems. I wonder what gives.

Yes, it's a bit strange. However, while preparing for testing your latest changes I noticed a new variation that might explain it partly: I removed my own workaround (very similar to your entityResponseOf-method, but in a helper class) on a single method in a single Resource. Before replacing it with your entityResponseOf-method I ran my code to verify that the problem was still there. This time, when fetching an entity with an "Å" in it, the browser rendered it correctly (😮 ?), but when I inspected the response in the chrome developer tools network-pane, it still appeared as two separate bytes ('Ã�'). Although I do not understand why the Sapper-middleware server did not crash this time, it could at least explain why you haven't noticed it in your apps when rendering entities in the browser window, as it seems it is more forgiving, when rendering these combinations (...perhaps!?).

Anyway, I applied your entityResponseOf-method, and then it worked as expected, and the "Å" was rendered correctly both in the browser window and in the response inspector (in the developer tools network-pane).

So all is good and I'm closing the issue 😃.