I've added possibility to specify http status code. According to specification http://json-rpc.org/wd/JSON-RPC-1-1-WD-20060807.html#ResponseStatusCodes status code may be changed to 500, 301 etc. Status code may be passed with "http_status_code" value passed into response info obj.
fixing empty params error
registry support for stateless services
response type fixed
Why do you want this change? Wouldn't it be just as easy to pass in  where required instead of undefined?
This 'undefined' is provided by rfc4627_jsonrpc_http:parse_jsonrpc/5 when no params are specified in POST request:
We may fix it there then.
Hmm, interesting. Reading the 1.1 JSON-RPC spec, it's hard to know what to do. So first off, I think you're right to fix it in rfc4627_jsonrpc_http:parse_jsonrpc/5, but the question then becomes: what should be done? My guess is that absent parameters should be treated like , exactly as you suggested in this commit. The spec says that params is optional, but then says that if it has a value other than an array or object, the server must reject the request with an error, which seems a bit contradictory.
Let's then support parameterless invocations. Fixed in mrspark/erlang-rfc4627@0080fdd
Merge remote branch 'upstream/master'
Revert "fixing empty params error"
This reverts commit 9fb4543.
parameterless procedure invocation support
httpd.hrl include path corrected
add possibility to specify http status code
merge from upstream
Hi - I like the idea of this patch, but I'm having trouble seeing the patch history cleanly. Could I get you to (a) rebase your master off tonyg/master, and then (b) open a fresh pull request? This one has a long and confusing history that is best dropped at this point, IMO.
I am newbie in git so could you please provide me instructions how to do this :)