One of the reasons why HTTP was chosen for the reference RPC was because it can be made proxy friendly.
Please open a JIRA on this issue to discuss. If you have an approach that is already in progress, submit a patch! Apache is a 'do-ocrocy'. I suspect there will be some discussion about backwards compatibility and the spec, but the experts on Avro RPC will have more to contribute to that discussion. Thanks, -Scott On 8/24/11 9:39 AM, "Shafi, Saleem" <[email protected]> wrote: > Hello all, > > We¹re experimenting a bit with Avro and we¹ve got a use case that I¹m hoping > to get some help with.. we¹d like clients to be able to send messages to a > server that would then forward the messages to a third-party (still in Avro), > but the messaging would be asynchronous.. the trouble we¹re running into is > with the schema handshake since there¹s someone between the client and the > ultimate recipient of the message.. we¹d like to avoid having the middle-man > open up the body of the HTTP request but we can¹t negotiate the handshake > without it.. > > Since the transport is abstracted out, would it make any sense at all to push > the handshake request into HTTP headers for the HTTP transport? Other > transports could still embed the handshake message with the rest of the > message, but by pushing the handshake into the headers for HTTP, a proxy like > ours could negotiate the handshake without opening up the body.. this could > arguably improve performance even in normal request/response scenarios since > the body wouldn¹t have to be parsed twice in cases where the client has to > resend the request with a new schema.. > > If this seems like a reasonable approach, we might be able to put together an > prototype implementation with one of the bindings and see if it makes sense to > adjust the spec.. > > Thanks, > Saleem.
