It seems like there is some fundamental misunderstanding about HTTP and the way the Siteminder WebAgents work.
Let mpe say a few words about the Web Agent. When the WebAgent (SMWA) (which may either be an Apache module or an application server plug-in known as TAI) receives a request for a protected resource, it will issue a redirect (302) to the login page (assuming Forms-based or challenge-response authentication is used) or a 401 (assuming basic authentication). If the authentication succeeds, the WebAgent will send a response containing a Set-Cookie header, setting a cookie named SMSESSION. If the WebAgent is configured to issue "Secure cookies", the cookie will be marked "secure" and can only be submitted by the browser over an SSL connection. I believe the path of the cookie will always be / and the cookie domain may either be explicitly set in the WebAGent configuration, or derived from the URL. The browser will include the SMSESSION cookie in all subsequent requests (Cookie header) satisfying the cookie path, cookie domain and security requirements. From time to time the WebAgent will issue a new SMSESSION cookie by injecting a Set-Cookie header into a convenient response. When the WebAgent receives a request for a protected resource, that contains a SMSESSION cookie, it will decode the cookie to identify the session and perform authorisation. If the request is authorised, it will inject a number of headers containing information about the session, including the session identifier, the user ID etc, the authentication level... into the request, but never into a response. Then back to your problem. If the request contains if-modified-since, it can only be because the browser already has a cached response. Siteminder never returns a SessionID header. It may return a SMSESSION cookie that must be submitted by the browser in all subsequent requests for protected resources. Something does not add up with your story: you claim the Apache server does not cache responses, but on the other hand you claim that Apache issues 304s. If Apache does not cache, it must be the WebSphere that issues the 304s, not Apache. Then, if the response is a 304, you do not expect the response to contain any other headers than the ones mentioned in RFC2616 10.3.5: all other headers are contained in the cached response on which the conditional request that elicited the 304 response was based. So the bottom line is that your problem is not what you think it is. You need to rephrase your question and better describe the scenario that fails, the headers submitted and the error you observe. -ascs -----Original Message----- From: Qingshan Xie [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 12:36 AM To: users@httpd.apache.org Subject: Re: [EMAIL PROTECTED] issue on 304 return code Thx a lot Joshua for your quick reply. We did some debugging. SiteMinder indeed returned all SiteMinder headers( Cookies and SessionID), but some how Apache in the front stripped them off and return 304. We did not implement cache, I don't know why it has if-modify-since in the header and return 304? Do you know why? Q.Xie --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] " from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
