On 12/10/2009 05:30 PM, Marc Gravell wrote:
> For info only, protobuf-net currently uses:
>
> internal const string HTTP_RPC_VERSION_HEADER = "pb-net-rpc";
> internal const string HTTP_RPC_MIME_TYPE = "application/x-protobuf";
>
>
> (version for my own internal purposes, in case I need to change the body
> layout)
>
> Re the sockets point also raised; there's a lot of difference between
> raw sockets and http; it would be good to get some kind of "official"
> http transport working - people can always add raw later...?
Totally. From your posts and Pavels, what about :
request :
-----------------------------------------------------
POST /{root}/{service full name}/{method name} HTTP/1.0
Content-Length: {length of the serialized message}
Content-Type: application/x-protobuf
{raw bytes of the serialized message}
-----------------------------------------------------
(and some other headers)
successful response :
-----------------------------------------------------
HTTP/1.0 200 OK
Content-Length: {length of the serialized response}
Content-Type: application/x-protobuf
{raw bytes of the serialized response}
-----------------------------------------------------
error :
-----------------------------------------------------
HTTP/1.0 500 Internal Server Error
Content-Length: {length of error message}
Content-Type: text/html
{some error message}
-----------------------------------------------------
Romain
> I'd rather
> not get bogged down in trying to predict every nuance of sockets, when
> people can always (for now) "do their own thing" using protocol buffers
> just for serialization.
>
> Marc
>
> 2009/12/10 Romain François <[email protected]
> <mailto:[email protected]>>
>
> On 12/10/2009 04:30 PM, Pavel Shramov wrote:
>
> On Wed, Dec 09, 2009 at 12:10:33PM +0100, Romain François wrote:
>
> Hello,
>
> Following Kenton's advice, I'm starting to look at
> implementing protobuf
> rpc over http. I have started to work on a basic java server
> (based on
> the com.sun.net.httpserver class). I will post this at some
> point when I
> am happier with it (currently it can only serve one dummy
> service that
> returns the input message as is)
>
>
> A request looks like this :
>
> -----------------------------------------------------
> POST /{service full name}/{method name} HTTP/1.0
> Connection: close
>
> Content-Length: {length of the serialized message}
>
> {raw bytes of the serialized message}
> -----------------------------------------------------
>
> I'm using method name encoded in query part of URL like
> /base/url?Service.Method
>
>
> That seems odd. Why not /base/url?service=Service&method=Method
> instead ?
>
> Also it's seem useful to provide Content-Type to distinguish
> between different
> encodings of message (for example JSON).
>
>
> Yep. Will add this.
>
> And a successful response looks like this:
>
> -----------------------------------------------------
> HTTP/1.1 200 OK
> Content-length: {length of the serialized response}
>
> {raw bytes of the serialized response}
> -----------------------------------------------------
>
> Also it may be useful to state that errors are transmitted as
> body of
> 500 Internal Server Error response.
>
>
> For my implementation You may see [1] and [2] for python and C++
> HTTP client.
>
>
> I will. So this makes 3 very similar http based protocols, but
> slightly different. We should come to an agreement. :-)
>
> Pavel
>
> [1] http://grid.pp.ru/wiki/pbufrpc
> [2] http://grid.pp.ru/cgit/pbufrpc
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/Gq7i : ohloh
|- http://tr.im/FtUu : new package : highlight
`- http://tr.im/EAD5 : LondonR slides
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
