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