Cannot change Content-Type of the response from backend http function

I have a http post function in the backend of my site and i would like it to return text/html as the Content-Type which i have set in the options. Although when I call the function the responses Content-Type is application/json.

Below you can see my code

export function post_acsexit(request) {

let options = {
“headers”: {
“Content-Type”: “text/html”,
},
“body”: “tt”
};

return ok(options);
}

I have exactly the same issue. Regardless of what I set the content-type to in my response.headers, the actually HTTP response (as shown by command line tools) is always ‘application/json’.
Can anyone shed light on this?!

Here’s my code:

export function get_htmlcode(request) {
const headers = {
 "content-type": "text/html"
  };

response.headers = headers;
response.body = `<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><body><b>hello</b> world</BODY></html>`.trim();
 return ok(response);
}

Here’s a snippet showing result of curl -v from command line.

> GET /website-2/_functions-dev/htmlcode HTTP/1.1 
> Host: webmaster4byoweb.wixsite.com 
> User-Agent: curl/7.54.0 
> Accept: */* 
>  
< HTTP/1.1 200 OK 
< Date: Tue, 17 Sep 2019 19:45:13 GMT 
< Content-Type: application/json 
< Content-Length: 95 
< Connection: keep-alive 
< server-timing: ttfb=0.644; "Time to first byte"

That is because the default Content-Type for Wix is application/json.

If you look through all of the Wix API reference for Wix HTTP Functions and it’s Wix Support pages too, you will find that it is all application/json.

https://www.wix.com/corvid/reference/wix-http-functions.html
https://support.wix.com/en/article/corvid-exposing-a-site-api-with-http-functions

Also note:
You must publish your site at least once before using both the testing and production endpoints. After that, you save your site for changes you make to testing endpoints to take effect and you publish your site for changes you make to the production endpoints to take effect.

How do I debug an HTTP function?
Each HTTP function you create has two endpoints, one for your users and one for you to use for testing. The testing endpoint is similar to the regular one, but the suffix -dev is added to the _functions in the URL. You can send requests to your testing endpoint in whatever way is most convenient for you, such as using a third-party tool like Postman . Learn more .

@givemeawhisky , thanks so much for your reply. But I’m still not clear. Generally when something is a ‘default’ that means it takes on that value (in this case ‘application/json’) if none other are specified. But here it’s not acting as a default, but rather as a static value that cannot be overridden.
This is not the documented behavior (unless I’ve overlooked something), though you are correct that all the documented examples show ‘application/json’ as the specified value for headers.content-type.
If the value will always be ‘application/json’ then why show examples of it being specified at all?

Everything else is working just fine so I’m not having any issues with testing or publishing the http functions.

1 Like

Yes I can agree with what you are saying, however there are certain things that Wix won’t let you change, like anything to do with the DOM for example, so users don’t fiddle with something and end up breaking their site.

However, I do believe that it still needs to be listed so that users will know what content-type that they have to use, although I would agree and would suggest that it was stated in the documentation for it that you can only use application/json and it can’t be changed or overridden for example.

@yisrael-wix We might have missed something here, however is it stated anywhere that the content-type application/json is the default and that we can’t change or override it with anything else?

Glad everything else is working fine for you though. :slightly_smiling_face:

@givemeawhisky
@yisrael-wix

I just ran into this myself, and it’s annoying as hell.
I understand that whole “we don’t want users to touch our fragile html so they nothing breaks”, but what does that have to do with this topic? There are a million different ways to bypass Wix and mess with the site’s HTML, and if you really want to do it, and you’re well-informed enough to be writing your own backend funcitons - I can guarantee you’re capable of doing that anyway. So how is this crippling limitation any help?

If this is intentional and not just some bug caused by some line that someone left in by mistake, it should really be reconsidered - there a ton of scenarios where it would be a completely legitimate to want to return something else other than application/json, be it HTML or XML or an image or whatever.

If this is an intentional behavior, maybe that should somehow be mentioned in the section talking about the headers? Because as it stands this doc is downright misleading.
https://www.wix.com/corvid/reference/wix-http-functions.WixHttpFunctionResponse.html#headers

@nimrodavid , you wrote - “There are a million different ways to bypass Wix and mess with the site’s HTML”

No - not really. The site’s HTML is off-limits. Accessing document elements such as div, span, button, etc is off-limits. The way to access elements on the page is only through $w. The HtmlComponent is sandboxed and restricted as well.

1 Like

@yisrael-wix
Sure, and if it helps to get this conversation to a productive place, I can promise you (because this seems to be taken like some personal issue, for some reason), that I’m not trying to use it to break any of MY OWN SITE’s html. That would be silly, right?

But what if I need to return XML? Or a CSV?
What if I need to return an empty pixel?
What if I need (as I do, in my specific case), to return a tiny piece of script that will be rendered inside an iframe after the submission of a form, and trigger navigation on the parent page?

Are these things we can agree on? Can we agree that there are use-cases to the idea of a backend function where there is a need to return a non-JSON response?
Can we agree that the documentation, as it stands, is unclear and misleading as for the behavior one should expect?

What if I need (as I do, in my specific case), to return a tiny piece of script that will be rendered inside an iframe after the submission of a form, and trigger navigation on the parent page?

You can do that.
https://support.wix.com/en/article/corvid-working-with-the-html-element
https://www.wix.com/corvid/reference/$w.HtmlComponent.html

Thanks for the suggestion, but I’m afraid these options don’t solve my issue.

I’m rendering a piece of third party content within an iframe, and after a form is submitted in that iframe it needs to redirect to a function on my site to do a bit of logic and then redirect to another page on the site.
I set up the function to return an HTTP redirect (302), but then only the iframe will change, not the whole page.

What I was trying to do is just return an HTML page from my function that contains only the one JS line needed to change the location of the parent page, which is the behavior I’m looking for.

@nimrodavid A “personal issue”? Nah. However, if you want to tell me that you like wheat beer, that’s different - we might need to talk.

@nimrodavid You can’t set the code in an HtmlComponent programmatically. However, if you’re proficient enough with HTML/Javascript (and as I understand it, you are), you can write a script that is self-modifying. That is, the script will accept a message with a chunk of code that it embeds itself. It gets a bit hairy, but I’ve done this myself for a couple of oddball projects so I know that it’s possible.

@Yisrael (Wix) I’m not sure I fully understand what you mean, but if I do, I don’t think it solves my issue.

I ended up having to host my own tiny HTML file that does what I need on S3, and I just have my backend function return a 302 redirect to it. This works, but it requires one extra round-trip that could have been avoided were we allowed to return other content types. And in general - it feels pretty silly, paying for and maintaining a fully-fledged website, but having to resort to an externally hosted file that I need to manage desperately. If it was for an actual technical reason - that would be a bit easier to swallow - but it’s not. The system has the capability to solve my (I believe, at least) legitimate need - but because of some design decision the cripples the system and limits the options, it won’t.

Again - I can get trying to protect people from messing up their own site - I just don’t think that this is doing it - or at least, that it’s doing it in a cost-effective way when you consider the loss of functionality.

I worked around this, just a shame I needed to ¯_(ツ)_/¯

Hi @givemeawhisky , do you have a sample script to your answer?