I use a RPC handler to extract the Set-Cookie headers to transmit the information to my code. As of 1.0.4.GA, the Set-Cookie headers are not present in the MIME headers anymore. Why?
Description
I use a RPC handler to extract the Set-Cookie headers to transmit the information to my code. As of 1.0.4.GA, the Set-Cookie headers are not present in the MIME headers anymore. Why?
I see that the fix version is 1.2.1. When is that scheduled to be released? I'd like to use 1.0.4 and above to benefit from the port change detecting mechanism. However, if cookies are not properly transmitted, I will have to revert to 1.0.3.
Chris Laprun [15/Feb/07 11:33 AM]
I see that the fix version is 1.2.1. When is that scheduled to be released? I'd like to use 1.0.4 and above to benefit from the port change detecting mechanism. However, if cookies are not properly transmitted, I will have to revert to 1.0.3.
The problem still exists if the server component of the web service doesn't access the HttpSession. This is problematic for WSRP in the case of Portal to Portal interaction. A workaround for the issue is to force an access to the HttpSession by the endpoints...
Chris Laprun [07/Apr/07 10:28 PM]
The problem still exists if the server component of the web service doesn't access the HttpSession. This is problematic for WSRP in the case of Portal to Portal interaction. A workaround for the issue is to force an access to the HttpSession by the endpoints...
Actually, forcing an access to the HttpSession in the endpoints fixes the issue starting with 1.0.4.GA so as far as WSRP is concerned, the issue is not solved for 1.2.1 since the current fix doesn't work unless the session is accessed by the endpoints.
Chris Laprun [07/Apr/07 10:34 PM]
Actually, forcing an access to the HttpSession in the endpoints fixes the issue starting with 1.0.4.GA so as far as WSRP is concerned, the issue is not solved for 1.2.1 since the current fix doesn't work unless the session is accessed by the endpoints.
In a web services, the client ant server component are fundamentally disconnected. i.e. your web service client could be talking to a .NET service implementation.
If the incomming (response) message does not contain the "Set-Cookie" header, the client cannot possibly read it. It is outside the scope of web service components to set these kind of transport related meta data.
#1 WSRP should not have to depend on cookies for state management - use WS-Addressing
#2 If WSRP must use cookies it should provide the server comonent that actually sets the cookie
It is non-sense to expect the core web service stack to associate session state with the transport layer i.e. a HTTP cookie.
Please understand that JBWS-1179 is in fact a bug that has been resolved and that your implementation relied on a side effect caused by this bug.
Thomas Diesler [10/Apr/07 04:07 AM]
In a web services, the client ant server component are fundamentally disconnected. i.e. your web service client could be talking to a .NET service implementation.
If the incomming (response) message does not contain the "Set-Cookie" header, the client cannot possibly read it. It is outside the scope of web service components to set these kind of transport related meta data.
#1 WSRP should not have to depend on cookies for state management - use WS-Addressing
#2 If WSRP must use cookies it should provide the server comonent that actually sets the cookie
It is non-sense to expect the core web service stack to associate session state with the transport layer i.e. a HTTP cookie.
Please understand that JBWS-1179 is in fact a bug that has been resolved and that your implementation relied on a side effect caused by this bug.
I don't expect JBWS to create a session on each invocation. I do however expect it to transmit headers that are available from the underneath HTTP transport. Tomcat is creating a session as a result of Portal invocations. As a result, it requests clients to set a cookie to be able to maintain this session. This cookie (or HTTP header) has NOTHING to do with the WS layer yet I expect the WS layer to transmit that information to my clients.
I am not quite sure what the consequences of forcing an access to the session in the endpoints is. More precisely, if this results in the creation of a new session (thus resulting in a different cookie), this is not the desired behavior. I need the cookie information set by Tomcat as a result of a WS invocation (but independently from it, i.e., as a result of my business logic) to be properly transmitted. This is not the case right now.
The WSRP specification mandates that consumers send any cookies that the producer sends therefore I need the headers to be properly transmitted. I don't write the spec, I just implement it.
Is it an expected behavior from the WS stack to not transmit information that is available at the HTTP level? If I do:
context.getHttpSession(); where context is an instance of ServletEndpointContext, in my endpoint methods, does that result in accessing the underlying HTTP session or in the creation of a new one? Do I need to write a server-side handler to set the Set Cookie header manually in the response sent to my clients?
Chris Laprun [10/Apr/07 05:44 PM]
I don't expect JBWS to create a session on each invocation. I do however expect it to transmit headers that are available from the underneath HTTP transport. Tomcat is creating a session as a result of Portal invocations. As a result, it requests clients to set a cookie to be able to maintain this session. This cookie (or HTTP header) has NOTHING to do with the WS layer yet I expect the WS layer to transmit that information to my clients.
I am not quite sure what the consequences of forcing an access to the session in the endpoints is. More precisely, if this results in the creation of a new session (thus resulting in a different cookie), this is not the desired behavior. I need the cookie information set by Tomcat as a result of a WS invocation (but independently from it, i.e., as a result of my business logic) to be properly transmitted. This is not the case right now.
The WSRP specification mandates that consumers send any cookies that the producer sends therefore I need the headers to be properly transmitted. I don't write the spec, I just implement it.
Is it an expected behavior from the WS stack to not transmit information that is available at the HTTP level? If I do:
context.getHttpSession(); where context is an instance of ServletEndpointContext, in my endpoint methods, does that result in accessing the underlying HTTP session or in the creation of a new one? Do I need to write a server-side handler to set the Set Cookie header manually in the response sent to my clients?
Bug
Resolved
Blocker
Regression: Set-Cookie MIME headers not available anymore?
* what jbossws version?
* request/response message?