http transport should behave more like other transports. -------------------------------------------------------- Key: JBREM-621 URL: http://jira.jboss.com/jira/browse/JBREM-621 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta1 (Bluto) The http transport makes special allowances for the possibility that HTTPClientInvoker might be connected to a server other than CoyoteInvoker and CoyoteInvoker might be connected to a client other than HTTPClientInvoker. However, it is possible for CoyoteInvoker to detect that its client is HTTPClientInvoker because HTTPClientInvoker sets a request property with key "User-Agent: and value beginning with the String "JBossRemoting". Some work toward this goal has already been committed in connection with JIRA issue JBREM-601. 1. If the return is null, CoyoteInvoker will return a response code of 200 instead of 204 if its client is HTTPClientInvoker. This is because returning 204 causes the client side response to return an empty input stream, which causes a problem for ObjectInputStream. 2. If its client is HTTPClientInvoker, CoyoteInvoker will wrap its response in an InvocationResponse. Currently, however, CoyoteInvoker does not treat raw invocations properly. In particular, if Client.RAW with value of true appears in the InvocationRequest metadata map, the raw payload is sent to the server, but, if it sees that its client is HTTPClientInvoker, CoyoteInvoker will still wrap its response in an InvocationResponse. The socket transport, on the other hand, will return the raw response in this case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira