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 <francoisrom...@free.fr > <mailto:francoisrom...@free.fr>> > > 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 proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.