Notification on transport that always returns response.

83 views
Skip to first unread message

bbkr

unread,
Oct 10, 2012, 6:25:12 AM10/10/12
to json...@googlegroups.com
I'm working on adding Notifications support for Perl6 JSON-RPC 2.0 implementation ( https://github.com/bbkr/jsonrpc ).

I'd like to use PSGI for server default HTTP transport layer, however it MUST return something to the client - it cannot just close the connection without sending any data back.

Is returning HTTP 200 with an empty response body a "most correct" behavior?

Matt (MPCM)

unread,
Oct 11, 2012, 10:11:37 PM10/11/12
to json...@googlegroups.com

Returning HTTP 200 is the approach I would recommend, as the requirement is that the server not generate a response object. But the http layer still needs to complete the call, and for practical reasons should return a 200 status code.

--
Matt (MPCM)

bbkr

unread,
Oct 12, 2012, 12:31:26 PM10/12/12
to json...@googlegroups.com
Thanks for response.

I've implemented suggested behavior - for Notification (or Batch containing only Notifications) server returns HTTP 200 with empty body and without "Content-Type: application/json" header.


Hoeger, Thorsten

unread,
Oct 12, 2012, 4:09:58 PM10/12/12
to json...@googlegroups.com
Hi,

maybe you can respond with HTTP Code 204 which means "No Content" to
make it easier for clients to tell the difference between "200 OK"
with content and 204 without response body.

Just my 2 cents

Regards,
Thorsten

2012/10/12 bbkr <pawel.pab...@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups
> "JSON-RPC" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/json-rpc/-/HghqiTiF4t0J.
>
> To post to this group, send email to json...@googlegroups.com.
> To unsubscribe from this group, send email to
> json-rpc+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/json-rpc?hl=en.

Mo

unread,
Oct 13, 2012, 6:44:19 AM10/13/12
to json...@googlegroups.com
Yes, http is being used as the transport in this case where as the json-rpc messages exist at the application layer.

The http response is akin to tcp ack packets if you were to send a json-rpc request directly over TCP/IP and is merely a necessary component of the transport.

HTTP offers the benefit that you can use the http response to encapsulate a json-rpc response, but In either case, so long as the node doesn't return a json-rpc response for notification messages you should be in compliance w/ the protocol.




On Wednesday, October 10, 2012 6:25:12 AM UTC-4, bbkr wrote:
Reply all
Reply to author
Forward
0 new messages