Greetings folks, According to JavaServer Pages™ specs v2.3 #JSP4.2, when a JSP page does not provide the TYPE value of the contentType attribute, "the initial content type is “text/html” for JSP pages in standard syntax"
With our relatively big web application, we are experiencing an intermittent issue which is a missing Content-Type header on some JSP pages and the issue goes away when we use 9.0.90+ or set org.apache.catalina.connector.RECYCLE_FACADES to true. Some of our clients are not easily updating their tomcat version so I would like to know what we are doing wrong maybe in our custom Filter that causes the occasional missing content-type when facades are not recycled. I got help from Konstantin Kolinko to locate some historical tomcat code changes. What I was trying to determine is details about the "recycle" method of the Request implementation and with Konstantin's help (see below), I make the reconciliation with the CoyoteRequest and the CoyoteRequestFacade classes. Now I can see the commit 301781 simply adds those. Is this coming straight on from a CVS repository ? If yes, can the CVS repository archive can still be publicly accessed ? At this point, I am not sure if commit 302827 ( https://svn.apache.org/viewvc?view=revision&revision=302827 ) would explain what i was searching for. My point is that at 301781 ( https://svn.apache.org/viewvc?view=revision&revision=301781 ), the facade is only cleared if Constants.SECURITY is true and now since 9.0.90, facades are cleared by default unless you change the option org.apache.catalina.connector.RECYCLE_FACADES to false. So following that logic, I found out what facade recycling was but I don't know why we rely on it. The missing content-type occurs when we navigate quickly between jsp pages. Here are some of the actions we performed in our custom Filter, 1. we are conditionally setting some headers on the Response object. 2. we are conditionally calling the RequestDispatcher.include method to add a JSP head ( stuffs like <html><head><meta /><script ... /><style ... /></head> ) 3. depending on an external authentication call result we are either sending a redirect or calling FilterChain.doFilter Please note that we tried the following without success: - declaring a default-content-type inside a jsp-property-group as prescribed by the JavaServer Pages™ Specification v2.3 #JSP.3.3.9 Thank you, Simon Arame ---------- Forwarded message --------- From: Konstantin Kolinko <knst.koli...@gmail.com> Date: Thu, Jul 18, 2024 at 2:15 PM Subject: Re: Earlier Tomcat source code To: Simon Arame <saxeo...@gmail.com> чт, 18 июл. 2024 г. в 19:23, Simon Arame <saxeo...@gmail.com>: > > Hi, > Thank you for this reply, is it ok if I forward this to the mailing list with additional questions ? > OK. Best regards, Konstantin Kolinko > On Thu, Jul 18, 2024 at 9:43 AM Konstantin Kolinko <knst.koli...@gmail.com> wrote: >> >> вт, 16 июл. 2024 г. в 22:44, Simon Arame <saxeo...@gmail.com>: >> > >> > Hi, >> > >> > I recently experienced a problem with tomcat that was fixed by release 9.0.90. >> > >> > However, i would like to get a way around the actual proposed fix which simply changes the default value of property org.apache.catalina.connector.RECYCLE_FACADES. >> > >> > And to understand what's going on, i'm trying to follow the commit history. >> > I first stumbled on your message https://svn.haxx.se/dev/archive-2011-09/0558.shtml that states that tc6 can not be browsed before 389146/389140 >> > then, i tried to follow the subversion history of the file org.apache.catalina.connector.Request.java which at revision 302975 changed from being an interface to being a class. the commit message mentioned it was copied over from Coyote Adapter, but when I go to coyote subfolder the Request.java that is there let's say at revision 302974 is the same class but at an earlier version. >> > >> > So i'm trying to fill the gap to understand what happened to that internal Request class between 302975 and earlier, let's say https://svn.apache.org/repos/asf/tomcat/connectors/trunk/coyote/src/java/org/apache/coyote/Request.java@301074 ... >> > >> >> Regarding looking up the old Tomcat sources >> >> 1. If you look at the commit message for r302975, >> https://svn.apache.org/viewvc?view=revision&revision=302975 >> it mentions "I'm using version number 5.5 for this refactoring, as an >> indication that this is no longer 5.0.x." >> >> Essentially, it looks like a commit that branched off Tomcat 5.5.x, >> and thus the earlier code is with Tomcat 5.0.x. >> https://svn.apache.org/viewvc/tomcat/archive/tc5.0.x/trunk/ >> >> >> 2. Tomcat consists of several Layers (or Components): >> >> Catalina is the container, i.e. Servlet container. It implements the >> Servlet specification. >> >> Coyote is the underlying implementation of network protocols (HTTP, >> AJP), and all that stuff. >> >> There are two "Request" and "Response" classes: one pair in Catalina, >> and one pair in Coyote. >> >> The CoyoteAdapter class is a component of Catalina. >> >> >> 3. In Tomcat 5.0 the relevant code is here: >> https://svn.apache.org/viewvc/tomcat/archive/tc5.0.x/trunk/container/catalina/src/share/org/apache/coyote/tomcat5/ >> >> Essentially CoyoteRequest class of Catalina [1] became Request class >> of Catalina [2]. >> >> [1] https://svn.apache.org/viewvc/tomcat/archive/tc5.0.x/trunk/container/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java?revision=588818&view=markup >> [2] https://svn.apache.org/viewvc/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/connector/Request.java?view=markup&pathrev=302975 >> >> If you look at commit 302975 closely, there is the following line: >> >> tomcat/container/catalina/trunk/catalina/src/share/org/apache/coyote/ deleted >> >> That is the directory that contained the old code. >> >> 4. If you go further into older code, the source control system at >> that time was CVS. >> https://en.wikipedia.org/wiki/Concurrent_Versions_System >> >> Essentially, CVS does not version directories. While with Subversion >> you can commit several files at once, with CVS you essentially commit >> single files. A migration tool essentially tried to recreate >> multi-file commits from individual files. Thus you may need to look at >> adjacent commits in the Subversion repository to see related changes >> in other files. >> >> 5. I think that you would better understand Tomcat code if you run it >> with a debugger. See >> >> https://cwiki.apache.org/confluence/display/TOMCAT/Troubleshooting+and+Diagnostics#TroubleshootingandDiagnostics-CommonTroubleshootingScenario >> >> and >> >> https://cwiki.apache.org/confluence/display/TOMCAT/Developing#Developing-Debugging >> >> >> Best regards, >> Konstantin Kolinko
