Azure-functions-host: ~0.9 to ~1.0 breaking changes: unable to return raw content

[yvele]

Problem

Same code with ~0.9 returns:

{"swagger":"2.0","info":{"version":"0.5.0","title":"test"},"host":"...

Now with ~1.0 I have everything in double quotes with escaped characters.. ?!

"{\"swagger\":\"2.0\",\"info\":{\"version\":\"0.5.0\",\"title\":\"test\"},\"host\":\"...

What happened? I can see no "breaking changes" in your 1.0 release....

Edit: Related to issues https://github.com/Azure/azure-webjobs-sdk-script/issues/958 (and https://github.com/Azure/azure-webjobs-sdk-script/issues/814)

Workaround

Switch back to ~0.9

[fabiocav]

@yvele, I've updated the release notes as those were breaking changes (by design). If you were returning a string, you should be able to return a JSON object from your function and get the expected results.

[yvele]

@fabiocav Nop, I need to return raw data. A way to return raw data is vital. It's so simple you have to break it? Why is Azure Function interfering here? Over-featuring everything.. This is really basic needs.

What if I need to return a simple utf-8 string? Impossible?
Plus what is the point of returning and escaping double quotes "foo" for a string?! (req.body = "foo";)

You cannot break this over simple functionality and doesn't give a way to achive it (buffer support is broken). I'm curious what @mathewc is thinking about that.. really..

PS: Sorry for my destructured comment but I'm a bit pissed off right now..

[fabiocav]

@yvele completely understand. We have added some features that have been requested and are important to users, but unfortunately that did remove the ability to write the raw response, but we agree with you! That should be there! And we're working on that fix ASAP.

I'll update this with the PR details as soon as I have it out. In the meantime, hang on to 0.9 for just a bit while that isn't there.

Apologies for the inconvenience! We're working to make sure you have what you need.

[yvele]

@fabiocav That's cool.. I was shocked by this unexpected breaking change. I'm not only focused on my own needs, I really think that simple feature will allow maximum affordance and flexibility.. this will benefits Azure Function adoption.

PS: I don't really understand the vision behind Azure Function right now.. The strategy looks like implementing a maximum of (random?) features to compete AWS Lambda and Google Cloud Functions.. Is there any writing about the particular vision that Azure Function have to offer to the community? Sorry for the digression.. but I'm really interested about the vision behind the product 😄

PS: Related PR https://github.com/Azure/azure-webjobs-sdk-script/pull/968

[fabiocav]

You found the PR :) Good... I was working on a couple of things and was going to share when ready.

Again, that capability was removed as a side effect of some features we wanted to deliver and we agree that it shouldn't have been. It did unfortunately go with breaking changes while we could afford to make them (during the preview/beta phase), but this was something we intended to fix. Now that we have released the service, you won't see breaking changes in minor versions.

About the vision, much of that information is shared publicly on the app service blog here https://blogs.msdn.microsoft.com/appserviceteam/ and posting questions about that topic there will get others to comment.

Again, I know you just found the PR, but I'll update this here again once it's finalized and merged. (This is being iterated on with a few internal tests)

[fabiocav]

Alright, @yvele, the change was merged in and will be in the next release.

As you noticed in the PR, we're introducing a response property named isRaw, which when set to true, will treat your response body as the raw response (which will give you a similar behavior to what you had in previous versions)

Thanks again for reaching out and for the patience with this!

[fabiocav]

Closing this as it has been addressed in #968 and will be in next release.

@yvele thanks again for reaching out with this. As a reminder, we do follow semantic versioning, so major version updates (as well as preview services) may, and likely will, introduce breaking changes. For that reason, major version updates do not happen automatically and we always recommend testing the new bits on a dev/test site before performing the upgrade.

I've updated the title to better describe the issue discussed and what was addressed. Content negotiation was actually one of the things that was fixed with the changes that happened from 0.9 to 1.0. The newly introduced flag allows you to, in addition to bypassing the formatters, opt out of that as well.

If you have any questions or run into any problems, please let us know!

[yvele]

@fabiocav Thanks. I'm aware that you are following semantic versioning. But the problem was not the breaking change but an unexpected feature removal (and such a basic feature).

Plus that string formatting looks so useless..

[davidebbo]

@yvele: @fabiocav's change is now deployed. Can you give this a try?

[fabiocav]

For reference, here is an example of that in use:

  context.res = {
            status: 200,
            body: '<root>body</root>',
            headers: {
                'Content-Type': 'text/xml'
            },
            isRaw: true
        }

We have also added a function to allow you to easily set that on the response. Here's an example returning JSON:

context.res.type('application/json')
        .raw('{ "prop" : "value" }');

Let us know if you have any problems

[yvele]

@fabiocav Thanks for the example.. I'll try it soon and let you know 👍

[yvele]

@fabiocav @davidebbo Ok I confirm ~1 is working with raw content 👍
FYI: Fixed in [email protected] with this commit

PS: Now waiting for native buffer support 😄