Please help us help you and fill where relevant:
Your LimeSurvey version: LimeSurvey Community Edition Version 6.2.11
Own server or LimeSurvey hosting: yes
Survey theme/template:
==================
Hey,
I want to know, why the response header of a RemoteControl-JSON-RPC-request is 'text/javascript' instead of 'application/json'?
It seems the header is set here: github.com/LimeSurvey/LimeSurvey/blob/9d...sonRPCServer.php#L81

Thanks

I'll move this into "Development" where I think it fits better.

Ok, thank you. Do you know the reason?

Do you know the reason?

If I would know the reason, I would have told you.

Looked into this a bit.

The original json rpc library limesurvey added and extended used text/javascript as the content type for the response. The original website for the code is gone, but I found a few forks. Most of them have changed this to application/json. Doing some googling, I reached the conclusion that application/json should be the content type used for json.

So I guess the reason is just that's what the original author of the library did and no one ever changed it.

bugs.limesurvey.org/view.php?id=19214

There are no rules on spec : www.jsonrpc.org/specification_v1 .
But seems more logical.

Can you send a PR for the update fork ? I like to read the explanation.

developer.mozilla.org/en-US/docs/Web/HTT...E_types/Common_types

search for json, yields application/json

here's a fork that's made the change (forked from same codebase LS uses):

github.com/tomgross/jsonrpcphp/blob/mast...sonRPCServer.php#L77

Hey,
It's described in this specification:
www.jsonrpc.org/historical/json-rpc-over-http.html

Content-Type SHOULD be 'application/json-rpc' but MAY be 'application/json' or 'application/jsonrequest'

It's NOT is V1 spec 2008 > 2005.

But i already answer seems better

It seems that this would need better explanation, perhaps in LS documentation. Rationale: The only people who use RPC are those who use it programmatically (Python, R etc. access). They are used to getting the existing kind of response. Thus implication is - existing code / workflow may break (it has bugs.limesurvey.org/view.php?id=19258 )

Therefore testing and some explanation how to migrate the code would be quite important. People who use RPC probably use it for the magic of automation of something that ordinary users don't know about but like to be able to use. If the magic breaks people cannot use the automation and turn to the person who introduced using RPC. Automation is usually needed to process a lot of data, hence breakage can affect a lot.

Would people please look into this aspect of testing and documentation?

OK, thanks everyone, this was quickly resolved by @mfavetti and @JanE:

@mfavetti made a PR for limer that fixes the issue.
Using that PR I created a new fork of limer with that PR
You can test it by running
CODE:
devtools::install_github("Jan-E/limer", force = TRUE)
See github.com/cloudyr/limer/pull/66 and github.com/Jan-E/limer

It should soon make it to the main release.