Possibility to specify HTTP Status Code has been added #8

Closed
wants to merge 9 commits into
from

Conversation

Projects
None yet
3 participants
@vkamensky

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.

@tonyg

This comment has been minimized.

Show comment
Hide comment
@tonyg

tonyg Oct 17, 2011

Why do you want this change? Wouldn't it be just as easy to pass in [] where required instead of undefined?

tonyg commented on 9fb4543 Oct 17, 2011

Why do you want this change? Wouldn't it be just as easy to pass in [] where required instead of undefined?

This comment has been minimized.

Show comment
Hide comment
@evolchek

evolchek Oct 18, 2011

Collaborator

This 'undefined' is provided by rfc4627_jsonrpc_http:parse_jsonrpc/5 when no params are specified in POST request:
https://github.com/mrspark/erlang-rfc4627/blob/9fb45432f9bc274690694f0a6933e354b3545955/src/rfc4627_jsonrpc_http.erl#L151
We may fix it there then.

Collaborator

evolchek replied Oct 18, 2011

This 'undefined' is provided by rfc4627_jsonrpc_http:parse_jsonrpc/5 when no params are specified in POST request:
https://github.com/mrspark/erlang-rfc4627/blob/9fb45432f9bc274690694f0a6933e354b3545955/src/rfc4627_jsonrpc_http.erl#L151
We may fix it there then.

This comment has been minimized.

Show comment
Hide comment
@tonyg

tonyg Oct 18, 2011

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.

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.

This comment has been minimized.

Show comment
Hide comment
@evolchek

evolchek Nov 1, 2011

Collaborator
Collaborator

evolchek replied Nov 1, 2011

This comment has been minimized.

Show comment
Hide comment
@tonyg

tonyg Nov 1, 2011

Thanks! Applied.

tonyg replied Nov 1, 2011

Thanks! Applied.

@tonyg

This comment has been minimized.

Show comment
Hide comment
@tonyg

tonyg May 15, 2012

Owner

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.

Owner

tonyg commented May 15, 2012

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.

@tonyg tonyg closed this May 15, 2012

@vkamensky

This comment has been minimized.

Show comment
Hide comment
@vkamensky

vkamensky May 15, 2012

Hi,

I am newbie in git so could you please provide me instructions how to do this :)

Hi,

I am newbie in git so could you please provide me instructions how to do this :)

@tonyg

This comment has been minimized.

Show comment
Hide comment
@tonyg

tonyg May 15, 2012

Owner

Well, I can point you at:

which should help. But it might take a bit of experimenting, in particular
because your history has some patches that were applied differently in my
history.

... OK so I've just done a rebase, and dealt with the inevitable problems;
I'll push the rebased version of your change to my repository soon. I
suggest you delete your fork of erlang-rfc4627 and get a fresh fork from
mine to work on going forward. Thanks for the contribution, by the way!

Regards,
Tony

On 15 May 2012 12:10, Valery Kamensky <
reply@reply.github.com

wrote:

Hi,

I am newbie in git so could you please provide me instructions how to do
this :)


Reply to this email directly or view it on GitHub:
#8 (comment)

Tony Garnock-Jones
tonygarnockjones@gmail.com
http://homepages.kcbbs.gen.nz/tonyg/

Owner

tonyg commented May 15, 2012

Well, I can point you at:

which should help. But it might take a bit of experimenting, in particular
because your history has some patches that were applied differently in my
history.

... OK so I've just done a rebase, and dealt with the inevitable problems;
I'll push the rebased version of your change to my repository soon. I
suggest you delete your fork of erlang-rfc4627 and get a fresh fork from
mine to work on going forward. Thanks for the contribution, by the way!

Regards,
Tony

On 15 May 2012 12:10, Valery Kamensky <
reply@reply.github.com

wrote:

Hi,

I am newbie in git so could you please provide me instructions how to do
this :)


Reply to this email directly or view it on GitHub:
#8 (comment)

Tony Garnock-Jones
tonygarnockjones@gmail.com
http://homepages.kcbbs.gen.nz/tonyg/

@vkamensky

This comment has been minimized.

Show comment
Hide comment
@vkamensky

vkamensky May 15, 2012

Thank you!

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment