On 05.05.2009 22:17, nohacks wrote: > 1) Which component should respond to this request, Apache or Tomcat? > > Tomcat should answer all. I am not using Apache to server any Static > content.
OK, and I assume you actually checked, that it *is* Tomcat that produces the answer in the 404 case. I forgot: Do you have the same problem, when using Tomcat directly via the HTTP connector without Apache? If so, we should debug it without Apache, because then it doesn't have to do with Apache. > 2)Which part of your webapps is expected to serve the content for > > Tomcat > > /a4j_3_2_2-SNAPSHOTorg/richfaces/renderkit/html/css/basic_classes.xcss/DATB/eAF7sqpgb-jyGdIAFrMEaw__.jsf > > We are using JSF and JBoss Richfaces. > > or there is some servlet, which should answer that request dynamically > and is not configured right, resp. the servlet producing the page which > contains this link produces garbage in the page. > > I dont think it is garbage, but you never know right. hahah. > > I see it returns a 200 here.. > > 78.124.0.12 - - [04/May/2009:10:26:27 -0400] "GET > /a4j_3_2_2-SNAPSHOTorg/richfaces/renderkit/html/css/basic_classes.xcss/DATB/eAF7sqpgb-jyGdIAFrMEaw__.jsf > HTTP/1.1" 2001254 "http://www.myAppName.com/login.jsf" "Mozilla/4.0 > (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; > Media Center PC 4.0; FDM; .NET CLR 2.0.50727)" The missing space after the "200" is due to a copy and paste error? It is somewhat misleading, when the most important information in the line (the status code) is corrupt. Can you call the URL directly, without going through the login.jsf by simply entering the long URL into the browser address line? The next thing would be to redo the same request, but making sure, that there is no session cookie send. So before sending the request and before each of the following tests, clean up all cookies in your browser. Especially that means do not go via the login page (which will likely set the cookie), always use the troubling URL direct. Do you also get a 200, when doing the same request without session cookie? Then simply add a ";jsessionid=123" at the end of the URL, redo the test (without cookie) to check what happens, if you use a session id for a non-existing session. If you can then reproduce the problem I would assume, that the 404 is produced by the JSF component itself. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org