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...? 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]>
> 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
>
>
--
Regards,
Marc
--
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.
