Re: window close session invalidate
This is a user question and should be posted on the tomcat-user list. On a side note, the session is maintained either by a session cookie or by a session id at the end of each request. The server will keep your session going for the time specified in the web.xml. If the client forgets all about the session id by closing the browser down, then the session is dead (even if it is still on the server until it expires). Hard to say why your popup doesn't work. One idea could be to make sure the session is going already in the root window. Martin On Wednesday, August 6, 2003, at 07:48 AM, Paul Wallace wrote: Also, I was under the impression that 'session' is good for the amount of time specified in your configuration file, or until session.invalidate(); is called? Thanks Paul. That is according to the spec, The session only lives for the time of the application,closing your browser window, means that you are ending your application Filip -Original Message- From: Paul Wallace [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 9:01 PM To: Tomcat Developers List Subject: window close session invalidate Dear all, May someone enlighten me on why my session is being invalidated when I close a browser window? I am doing this in one of two ways - the application close icon on the top right of the window, or a simple: a href=javascript:window.close();CLOSE/a Does anyone have any experience of this? The session is being killed and thus so is my app. I will submit this query to the user list, but thought it appropriate for this list as I am getting the same result from multiple instances of TC on different servers, implying it is not a configuration issue as first suspected. Thanks Paul. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java
On Tuesday, July 22, 2003, at 09:24 AM, Remy Maucherat wrote: Jan Luehe wrote: This is a pretty bad implementation IMO. What's the use of disabling this feature ? The spec declares these headers as optional, which means Tomcat should make them configurable. Some sites may prefer not to include this information in their responses, for security reasons or whatever. IIS 6 has similar headers, and I believe do not have any option to hide them. This has no bandwidth savings or anything. It is not worth adding flags everywhere for that. If you really want to add a flag, add it on the connector, and set the header in the CoyoteAdapter. As for the JSP flag, it should be a Jasper option if you really want to have it optional, not based on a bad test (why does the presence of a X-Powered header indicate anything ?). BTW, I don't see why the spec saying that the header is optional implies that the flag must be implemented as something optional. It merely means that an implementation may ignore completely this feature. I maintain my -1 (sorry for disliking your patches these days): adding configurability, down to flag addition in the core interfaces, to such a trivial feature is ridiculous (or we should have 300 flags in the Context interface, which we obviously don't want). Please revert your patch. Remy, I don't agree with that at all. For security reasons you always want the option to reveal as little as possible about your system. By default httpd creates headers like: Server: Apache/1.3.26 (Unix) mod_jk/1.1.0 DAV/1.0.3 mod_ssl/2.8.9 OpenSSL/0.9.6b Which for a paranoid sysadmin is far too much info to give away. Thankfully you can get rid of them in the httpd configurations (if you want another example look at bind and what that gives away by default). This is exactly the same thing, if the header is to be set in the response (I'm not commenting on the implementation details or wether it should be there), then there must be an option to turn it off. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java
You're using in your argument the most extreme example ;-) Here, it's only revealing the technology used. This is very little, and not any more revealing than a .jsp extension. Well, at least it sort of illustrated my point (sledgehammer to crack a nut) :) ... Yes the header itself doesn't reveal much, but there's also inferred knowledge such as the existence of this header indicates possible TC 5.0.x. But then you didn't mind having the config switch so why am I sending this email? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connection Pooling
This list is for developing the tomcat server. Your question is a configuration question and should be directed to the tomcat-user list. Martin On Monday, July 21, 2003, at 02:00 PM, sathya narayanan wrote: hi , IS there is any way to Connect Database using DBCP.jar without giving username and password in the server.xml file. Doc tells that we can pass the uname and password in the getConnection() method of DataSource . But it is give me an Exception . Plese help me. sathya _ It's new, it's here! It's full of fun! http://server1.msn.co.in/sp03/messengerpromo/index.asp MSN Messenger V6.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] hotfixes
Hello, I don't agree with Glenn or Yoav. For each tomcat 4.1.x version I use there are a couple of things I have to fix over and over again. My approach to making changes is: 1) take the official binary release of tomcat and 2) make *minimal* changes to address the problems I have with it. Currently I end up with compiling a couple of java classes manually with the destination directory being the server/classes such as: javac -d /jakarta-tomcat-4.1.24/server/classes StandardContext.java I strongly don't want to replace the whole 'catalina.jar' because of my tiny change (risking screwing something up unintentionally). I can clearly see a benefit of also having an option to deploy my changes as a jar instead of the .class files I now end up with. I wasn't aware that the .jar files were not sorted alphabetically (and that explains some trouble I've had in the past trying to rely on it). I strongly suggest they should be, it doesn't hurt and will probably help silly users like myself. However I'm not sure about a 'hotfix-' kind of prefix for jarfiles since it is not explicit enough (you have to know you can create a file with that name and that it will be priorities over other jar files). I think a better approach would be to have a 'lib-hotfix' directory so you get a visual indicator that the possibility of hotfixes exist. Martin On Friday, July 18, 2003, at 02:32 PM, Glenn Nielsen wrote: Well stated, I agree with your concerns. Shapira, Yoav wrote: Howdy, Currently o.a.c.startup.ClassLoaderFactory just does a standard directory listing. It might be nice to have the directory listed sorted in some manner so files with certain attributes might be loaded first. I was thinking of either - sorting by date - looking for hotfix--MM--hh-mm-ss.jar (or similar) first and sorting those files by name so the newest ones get loaded first. Comments? There used to be servers that did this (IPlanet and JServ come to mind, both using alphabetical sorting), and the amount of hassle that caused to developers was huge. Even to date, I see developers who rely on jar loading order to resolve having two classes with the same name in the JVM. I don't think this is a good idea. In the case for a hotfix, I would rather see a new jar altogether, replacing an existing jar. Not an addition, not an expansion, nor some fancy overriding mechanism. It significantly increases classloading debugging capability (which jar did this class really get loaded from?). I also tend to not fully agree with your beginning premise: One feature of enterprise ready software is the ability to apply small patches to an existing system. That's a nice to have, not essential, and a deterrent due to the above reasoning in the worst case. I would consider tomcat enterprise-ready now, without this feature per-se. Perhaps I'm misinterpreting what small patches are, though? Did you have examples in mind? I think it's the component owner's responsibility to provide the fix/patch, and to do so in the manner best fitting the component. In most java cases, I think that's an updated jar. If the fix requires many jars, then probably the product wasn't properly divided into modular jars to start with. I don't mean to sound extreme on this ;) I've heard far worse ideas. But I think for a general purpose server this causes more possible confusion and problems for users than it does good. Yoav Shapira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: question on how to work IIS with Tomcat
tomcat-dev is for developing Tomcat. This question is a user question and should be directed to the tomcat-user list. Martin On Wednesday, July 16, 2003, at 04:38 PM, Dhar, Subhashish wrote: Hello I try to configure the Tomcat in-process to work with IIS,I did all the configuration as suggested by Document, and restart IIS,The index.html page work, but the JSP and servlet didn't work .If I try to run jsp or servlet,the browser tell me to wait looking for the website. and then it display page not found. I have a question there are two uriworker.properties file one in jk directory and one in auto directory. I modified the one in jk directory. Am I doing the correct way? just wondering. I makes all the change in the worker.properties file as given in the document. but the jsp and servlet don't work unless I physically start Tomcat. I would appreciate if any one can help me and let me know where I am making mistake. I hope to hear from you soon. Thanks Best Regards Subhashish Dhar Purdue Pharma L .P One Stamford Forum Stamford, CT 06901-3431 Tel : 203-588-7469 [EMAIL PROTECTED] www.purduepharma.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WebdavServlet.java, form based login and files from other contexts
In a recent client project I used the WebdavServlet for the first time and encountered some configuration issues which lead me down the path of doing some patches to it. Our client's site uses form based login which doesn't play well with WebDAV. All clients I've ever seen only do basic authentication. The problem is really that one web app can only have one type of login (I would like to be able to set different login types for different security-constraints in the same app). Changing to basic login is not really an option since that makes the site less slick, and part of the project was explicitly to do form based login. The only way I can see to solve the problem was to add another parameter into the WebdavServlet so that it can server files of another context, in my configuration a /webdav webapp serves files off the ROOT (/) context. The changes to the WebdavServlet to do this are very trivial, add another parameter fileContext and override the getResources() method in the DefaultServlet with an exact copy except that rather than grabbing the local context, the method can now grab a foreign one if fileContext is set. The added bonus with this solution is that .jsp files can be served from the the ROOT context through jasper, while the source code can be served in my /webdav context. Is this an okay solution? Is it the right way of doing it? ... Shouldn't really the WebdavServlet be able to serve an arbitrary path of the file system? Have anyone else had the same problem, should the WebdavServlet be possible to configure along these lines? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WebdavServlet and security constraints
In a recent project we cooperated with our client in building a site. They were doing static html files and we took some of them and turned into JSPs. In order for our client to be able to update their site, we enabled webdav on the webapplication. However, we don't want them to be able to update our JSPs which lives in the same webapp as their static content. We see it as a security risk to be able to write arbitrary JSP code that gets executed on our servers. The neatest way of doing this protection was in the web.xml: !-- This constraint makes sure no JSP files are overwritten but they can still be downloaded. Only dangerous http-methods are forbidden. -- security-constraint web-resource-collection web-resource-nameForbidden/web-resource-name url-pattern*.jsp/url-pattern !-- http-methodGET/http-method -- http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method !-- http-methodOPTIONS/http-method -- http-methodPATCH/http-method !-- http-methodPROPFIND/http-method -- http-methodPROPPATCH/http-method http-methodMKCOL/http-method http-methodCOPY/http-method http-methodMOVE/http-method http-methodLOCK/http-method http-methodUNLOCK/http-method /web-resource-collection auth-constraint !-- No roles, which means no one is allowed -- /auth-constraint Which works a charm, however it does not protect us for MOVE operations. The webdav client can still create a file such as file.txt and rename it to file.jsp and then execute it. This is because when renaming file.txt to something else the HTTP request issues is MOVE /file.txt and only later in the XML blurb is the destination file specified. Now really what I would like to do is to make a move filea.txt fileb.jsp from a security point to be equal to a DELETE filea.txt and PUT fileb.jsp. If the user is allowed to do these two operations, then he/she is allowed to do the MOVE. Is there a nice server side way of doing this security check? I don't think the servlet API exposes anything useful. The only generic way of doing it that I can think of is constructing URL objects that calls my own servlet (and of course the added grief of copying over security headers etc) with some URL parameter that tells the servlet that the operation is only for test. The other way is to do a TC specific solution, if I only could get hold of the internal APIs I could easily check this. I found the SecurityConstraint object which resides in the StandardContext object. However these classes seems very internal to TC and I suspect there is no good way of getting hold of them from the WebdavServlet, right? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ap..cache
Fabio, We're achieving a good cache result by using mod_proxy and its built in proxy cache. We have: Front servers that do caching and backservers that runs the tomcat. The fron servers runs apache and mod_proxy. Any request coming in to example www.foo.com/index.jsp is proxied through to the back hosts where another apache is listening on port 80. The apache on the back host uses mod_jk to connect to Tomcat which serves the page. mod_proxy on the fron hosts has a proxy cache which can be used to cache our jsp pages. There are some simple rules to follow when you want a jsp to be cached in a generic web cache (see HTTP protocol for details on web caches). We got it sorted so that a request that comes into the front hosts, will only result in a revalidation (If-Modified-Since) to the back hosts. The jsp page can be coded to deal with this type of request and can then tell the front hosts to serve the cached page or return a new one. Martin -Original Message- From: Fabio Salvi [mailto:[EMAIL PROTECTED]] Sent: 29 January 2003 10:43 To: [EMAIL PROTECTED] Subject: Ap..cache Hi all, recently I've been thinking about a way to implement a cache mechanism in Apache-Tomcat interaction (e.g. ajp13). I'd be really grateful if you gave me some suggestions or advice on the matter. Below I shortly describe what I've built as a kind of prototype. To sum up, I've modified mod_jk (win2000) in some points in order to make it cache-aware. I've introduced in httpd.conf the following directives: # # normal jk directives # JkMount /*.jsp ajp13 #Cache extensions JkCache on JkCacheDirectory C:\cache This is, basically, the collaboration diagram I've implemented: . mod_jk intercepts request for /pippo/cachetest.jsp; . mod_jk asks Tomcat, at the moment actually a WebApp controller, for a list of dirty items in cache folder; . then, mod_jk deletes dirty-bit pages in the cache; . now mod_jk manages current request. If it finds the page in the cache it returns static file to Apache. . Otherwise it requires the resource back to the WebApp controller. The latter knows if the page is to be cached and puts a special tag on the byte stream in response, after having dynamically built it; . mod_jk receives the response and if it does contain the above mentioned tag, mod_jk writes it in the cache folder before sending it to Apache. If there's a query string, it'll include it in the static resource name. The second and third steps are an overload respect to normal interaction, but that permits to save a lot of elaborating time and network roundtrips when you ask for a very heavy resource (e.g a jsp which loads many non-volatile and quite stable data from a db). All that seems to work fine...According to your opinion is a worth-to-develop idea? Thanks in advance for your advise! Fabio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: strange messages in tomcat 4.1.18
Thanks for explaining that. I've referenced your answer in an enhance request with the patch (16357). Martin -Original Message- From: Hannu Kivimäki [mailto:[EMAIL PROTECTED]] Sent: 23 January 2003 11:20 To: [EMAIL PROTECTED] Subject: Re: strange messages in tomcat 4.1.18 Hello Martin and Raiden, Subject: RE: strange messages in tomcat 4.1.18 Date: Wed, 22 Jan 2003 12:41:03 - From: Martin Algesten [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] I've asked myself this question. (I think) the messages are about a connection being left open (as in Keep-Alive and then being closed by the client. I'ts easy to find the where this output is made from in the source. It might be that INFO is a tad much for this kind of messages (perhaps DEBUG would be better?) ... However the logging system jk uses seems to be configurable, and in theory it should be possible to change the level of output for this component. However I can't find any documentation on how to do this, and 5 minutes of glancing at the source does not give any hints... Is there documentation for this? Perhaps a point in the JK FAQ about this message? Martin -Original Message- From: Raiden [mailto:[EMAIL PROTECTED]] Sent: 21 January 2003 18:40 To: [EMAIL PROTECTED] Subject: strange messages in tomcat 4.1.18 Hello, I apologize for posting this question to this group, but I have been unable to get an answer in the tomcat-user group. My catalina.out logs are full of the following messages: Jan 21, 2003 10:31:41 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Jan 21, 2003 10:31:42 AM org.apache.jk.common.ChannelSocket processConnection ... Assuming these are non-harmful messages (are they?), is there a way to turn them off, so that they're not flooding my logs? They appear to happen everytime an apache/mod_jk/mod_jk2 worker creates a connection to Tomcat. Thanks, Raiden This has been discussed briefly before, see http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg3 8339.html If you are using Apache (1.3.x, don't know about 2.0.x) as web server, this message simply means that an Apache child process was restarted. And yes, these are non-harmful messages. See http://httpd.apache.org/docs/mod/core.html#maxrequestsperchild if you'd like to change the restart frequency (there's probably no need to). To prevent messages from showing up in catalina.out you need to adjust logging level for org.apache.jk.common.ChannelSocket. AFAIK this cannot be done by altering log settings in server.xml. Instead, add line org.apache.jk.common.ChannelSocket.level = WARNING to the end of logging.properties in JRE 1.4.x's lib directory (by default /usr/java/jre/lib in Solaris, /usr/java/j2sdk1.4.x/jre/lib in Linux). If you don't want to mess around with default logging file, you can make a copy of it and add parameter -Djava.util.logging.config.file=somefile into Tomcat startup script. I'd vote for changing log level of these server has been restarted... messages from INFO to DEBUG in next Tomcat release. There's enough settings to do even without tampering JRE's property files. :) Hannu -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 5 target JDK1.4?
-Original Message- From: V. Cekvenich [mailto:[EMAIL PROTECTED]] Sent: 21 January 2003 23:04 TC5 is ways of. And I think everyone can agree that JDK1.4 is more stable than 1.3. I don't agree. Stability is the sum of your whole infrastructure, API, web servers etc etc. Most of my old sites are 1.3 and a handful of new ones are on 1.4, for my purposes seem to be as stable as another. Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 5 target JDK1.4?
-Original Message- From: Sean Reilly [mailto:[EMAIL PROTECTED]] Sent: 21 January 2003 23:37 To: Tomcat Developers List Subject: RE: Tomcat 5 target JDK1.4? The many other arguments against requiring 1.4 notwithstanding (and I'm not attempting to refute _any_ of them here), it would seem to me that testing a major version change of Tomcat + a JVM change wouldn't incur much more overhead than testing a major version change of Tomcat alone. Does anyone have any comments/opinions/counterarguments? Or should I just shut my trap and concentrate on the other reasons requiring J2SE 1.4 is a bad idea ;-) I'm very happy that Tomcat works well on 1.4, I can't however see any reason to requiring 1.4, what are the benefits? Should we artificially create obstacles for the sake of it? Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: strange messages in tomcat 4.1.18
I've asked myself this question. (I think) the messages are about a connection being left open (as in Keep-Alive and then being closed by the client. I'ts easy to find the where this output is made from in the source. It might be that INFO is a tad much for this kind of messages (perhaps DEBUG would be better?) ... However the logging system jk uses seems to be configurable, and in theory it should be possible to change the level of output for this component. However I can't find any documentation on how to do this, and 5 minutes of glancing at the source does not give any hints... Is there documentation for this? Perhaps a point in the JK FAQ about this message? Martin -Original Message- From: Raiden [mailto:[EMAIL PROTECTED]] Sent: 21 January 2003 18:40 To: [EMAIL PROTECTED] Subject: strange messages in tomcat 4.1.18 Hello, I apologize for posting this question to this group, but I have been unable to get an answer in the tomcat-user group. My catalina.out logs are full of the following messages: Jan 21, 2003 10:31:41 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Jan 21, 2003 10:31:42 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Jan 21, 2003 10:31:43 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Jan 21, 2003 10:31:45 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Jan 21, 2003 10:31:47 AM org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection Assuming these are non-harmful messages (are they?), is there a way to turn them off, so that they're not flooding my logs? They appear to happen everytime an apache/mod_jk/mod_jk2 worker creates a connection to Tomcat. Thanks, Raiden -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 5 target JDK1.4?
In Java, the whole point is you can go switch out a VM, at a drop of a hat. I mean, JDK 1.5 is coming out. That's just moronic and plain wrong and if you truly believe that I'm feeling sorry for you. If you'd had any experience running live servers you'd know that changing API's _always_ have consequences. I'm worried about even changing trivial things like upgrading minor versions of XML parsers. To change the VM I rely on is a serious undertaking and certainly not done at a drop of a hat. But if I am the only one asking, maybe I am drunk. The thing is go to your IDE (IDEj) and flag target 1.4, do you see all the import changes? IDE? Flag target 1.4? That says it then. The first thing I ask programmers I hire is How do you prefer to program? What is your environment like? ... If the answer is along the lines of vi, emacs, notepad, zsh, bash, windows command line, then I feel much relieved... Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Making PureTLS work
This list is for development of the Tomcat please forward to tomcat-user etc etc ;) Martin (sorry, couldn't stop myself) -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 21 January 2003 15:04 To: Tomcat Developers List Subject: Making PureTLS work Hi, I was wondering if people among the happy few who got PureTLS (0.9b3) running with Tomcat 4.1 or 5.0 post some kind of small HOWTO. I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1). I read on the PureTLS website (err, sorry webpage) that it supported OpenSSL certs. So I should be able to reuse the certs I generated for mod_ssl ? Anyway, that's for later. In order to avoid making mistakes, I reused the .pem files I found in the distribution. After tweaking my server.xml to point at the right files (of course, I had to read the sources to know how to do it), I got the following exceptions: - with IBM JDK: Caused by: java.lang.InternalError: java.security.NoSuchAlgorithmException: class configured for Cipher: com.ibm.crypto. provider.DESedeCipher is not a subclass of xjava.security.Cipher at COM.claymoresystems.crypto.PEMData.readPEMObject(Unknown Source) at COM.claymoresystems.crypto.EAYEncryptedPrivateKey.createPrivat eKey(Unknown Source) at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown Source) at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown Source) at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(P ureTLSSocketFactory.java:165) at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.create Socket(PureTLSSocketFactory.java:104) at org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTc pEndpoint.java:275) - with Sun JDK: java.io.IOException: PKCS#5: Invalid number of padding bytes at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(P ureTLSSocketFactory.java:175) at org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.create Socket(PureTLSSocketFactory.java:104) at org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTc pEndpoint.java:275) at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:150) If PureTLS isn't compatible with IBM JVM, then fine, but I can't see its usefulness. As for the error with Sun VM, I don't know what to do (there doesn't seem to be any docs at all anywhere) ... Any ideas ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 5 target JDK1.4?
I use vi for at least 14 years, but for java dev I turned to eclipse last year, and it's hard to reswicth to vi ;) Wow! I tried to use Borland J something or another a long time ago and got to frustrated that I didn't have control over what I was doing... what are the advantages? Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 16258] - getContext does not work on default context
Believe me, when your different web apps are relying on actually being able to use this part of the API to communicate with each other, then this is a blocker... Martin (who still doesn't understand why this isn't an issue worth fixing) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 20 January 2003 15:05 To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 16258] - getContext does not work on default context DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cg i?id=16258. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16258 getContext does not work on default context [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-01-20 15:05 --- Try to do a query before filing a bug, as well as assign sensible severity level. *** This bug has been marked as a duplicate of 13040 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 16258] - getContext does not work on defaultcontext
I know I've taken several stabs at fixing this (e.g. submitting loads of patches). And I know some of them broke more than fixed. However have you reviewed the latest patch I did? If it still breaks, please tell me why so I can do a proper one. Martin -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 20 January 2003 15:11 To: Tomcat Developers List Subject: Re: DO NOT REPLY [Bug 16258] - getContext does not work on defaultcontext Martin Algesten wrote: Believe me, when your different web apps are relying on actually being able to use this part of the API to communicate with each other, then this is a blocker... Martin (who still doesn't understand why this isn't an issue worth fixing) Because your fix breaks more things, and makes a Watchdog test fail. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 16258] - getContext does not work on defaultcontext
BTW. I'm not asking you to test my fixes... I'm using that fix myself. Martin -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 20 January 2003 15:11 To: Tomcat Developers List Subject: Re: DO NOT REPLY [Bug 16258] - getContext does not work on defaultcontext Martin Algesten wrote: Believe me, when your different web apps are relying on actually being able to use this part of the API to communicate with each other, then this is a blocker... Martin (who still doesn't understand why this isn't an issue worth fixing) Because your fix breaks more things, and makes a Watchdog test fail. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Remy, once again we agree :) M -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 17 January 2003 14:19 To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 16001] - Tag.release() not invoked DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cg i?id=16001. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001 Tag.release() not invoked [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-01-17 14:19 --- Your tag does not comply with the JSP specification, and, as a result it may or may not work. This issue WILL NOT be fixed in Tomcat. Thanks, and DO NOT REOPEN THIS BUG. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Duplicate session IDs are *common*
Note that you would need 1 million sessions that are active at the same time - if a session expires and the id is reused there is no harm. If I leave my browser open and go for lunch and someone else gets my expired session id, I return and continue browsing, wouldn't that cause problems? Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: hello
This is the developer list for development questions. Please direct this question to the tomcat-user list. ( Tip: Have a look at web.xml error-page directive: error-page error-code404/error-code location/error404.jsp/location /error-page error-page ) Martin -Original Message- From: Dan Agarlita [mailto:[EMAIL PROTECTED]] Sent: 09 January 2003 10:33 To: 'Tomcat Developers List' Subject: hello I want to know how can I modify the 404 Error page. I want to put another page. Is a param? Or I have to modify some classes ? :) 10x, dan -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk and load balancer - bug?
A redirect can't be done relatively... The HTTP/1.1 spec for the Location: header states: The field value consists of a single absolute URI. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 So the server must figure out how to construct an absolute URL. I've been bitten by the same thing but in another context where I terminate SSL on my front servers and then forward the traffic onto port 80 on my back servers, however I do set the apache environment variable HTTPS=on which means that my java API gets fooled into thinking the URL was secure, e.g. request.isSecure() returns true request.getScheme() returns https, however request.getPort() returns 80, so when I do a redirect it constructs the URL as https://someserver:80/something; which fails... I would like to see a good solution to these redirection/port/hos issues once and for all. I believe it should be completely configurable on the connectors what host and port should be used for redirection for https and http. There are several bits to solve, and there must be separate configurations for http and https. 1) hostname changes, e.g. request comes in to host A and is forwarded by mod_proxy or similar to host B. 2) port changes, e.g. request comes in to host A on port 80 and is forwarded by mod_proxy or so to host B port 1234. 3) context changes, e.g. request comes into http://A:80/some/path/this and is rewritten to http://B:1234/path/this ... I use this to have a shared SSL certificate e.g. https://shared.host/site/www.somesite.com/webapp/path is rewritten to http://www.somesite.com/webapp/path in a generic way. This goes completely pear shaped since session cookie path is set to /webapp and that results in the browser being completely confused. (It doesn't send the cookie back since the requested URL is not https://shared.host/webapp;. I haven't thought through what needs to be done to solve any of this. But one day I'm sure I get time to do it :) Martin -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED]] Sent: 17 December 2002 01:11 To: Tomcat Developers List Subject: mod_jk and load balancer - bug? here is a scenario hardware stack LoadBalancer(port80) - Apache/mod_jk 2.0.43(port81) - Tomcat 4.1.12(port8080/8009) 1. The load balancer receives a request for http://server/somecontext/ 2. The load balancer forwards this to apache. Apache detects /somecontext/ and makes a request to Tomcat 3. Tomcat gets the request GET /somecontext/ and looks up welcome files 4. Tomcat finds index.jsp as a welcome file 5. Tomcat constructs a redirect using the absolute URL it got from Apache and here is the problem, in step 5 tomcat constructs an absolute URL, and uses the port number from Apache which was 81. hence the redirect will go to port 81. the response back to the server is Location:http://server:81/somecontext/index.jsp --which is wrong, the request came in on port 80 when it would have been better if the response was the relative URL. Is this a bug, or could we add a feature to be able to configure the Coyote connector to generate absolute or relative urls on sendRedirect Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: error-page status codes broken, no response to bugzilla report
The problem with this bug is that there are people here who don't agree it is a bug... which is just plain ignorant and stupid... THIS IS A BUGIT NEEDS FIXING! I've tried get this one sorted as well... however, either someone will tell you they don't agree it is a bug and/or they will just ignore you until you go away. Martin -Original Message- From: Donald Ball [mailto:[EMAIL PROTECTED]] Sent: 19 December 2002 15:55 To: [EMAIL PROTECTED] Subject: Fwd: error-page status codes broken, no response to bugzilla report What does one have to do to get a response to a bug report around here? I submitted it to bugzilla, I followed up here. If it's a bug, I'm happy to help patch. If I'm an idiot, I'd appreciate being told so. - donald On 12/18/2002 at 1:00 PM Donald Ball [EMAIL PROTECTED] wrote: I submitted this bug report a few days ago: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15406 It seems to me that tomcat is doing the wrong thing when it tags the error page contents with status code 200 instead of the actual error status code. If this is the case, is anyone interested in fixing tomcat? If this is not the case, can someone try to explain why tomcat's behavior is correct? - donald -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspWriterImpl.java
Interesting log comment...
Martin
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 19 December 2002 16:30
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runt
ime JspWriterImpl.java
remm2002/12/19 08:29:58
Modified:jasper2/src/share/org/apache/jasper/runtime
JspWriterImpl.java
Log:
- I don't see any need to create a session here (and it messes up
with my testing).
Revision ChangesPath
1.6 +3 -5
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runt
ime/JspWriterImpl.java
Index: JspWriterImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j
asper/runtime/JspWriterImpl.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- JspWriterImpl.java 29 Oct 2002 00:53:02 - 1.5
+++ JspWriterImpl.java 19 Dec 2002 16:29:58 - 1.6
@@ -197,8 +197,6 @@
flushBuffer();
if (out != null) {
out.flush();
-// Also flush the response buffer.
-response.flushBuffer();
}
}
--
To unsubscribe, e-mail:
mailto:tomcat-dev- [EMAIL PROTECTED]
For
additional commands,
e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtimeJspWriterImpl.java
I will not say anything about a certain operating system and point'n'click kind of user interfaces, even if it is very tempting ;) Martin -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 19 December 2002 16:42 To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runt imeJspWriterImpl.java Remy Maucherat wrote: Martin Algesten wrote: Interesting log comment... Why's that? I'm using ab to test (against that page, as it's easier), and it's too dumb to use sessions. So it ends up creating thousands of sessions (1 request - 1 session) very quickly, messing the test results (since I'm not trying to test how many sessions can exist before my VM dies). Ooops, I understand now. Wrong CVS message indeed (caused by a WinCVS feature). Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Apache+Tomcat+modjk with ~/public_html
tomcat-dev is for development/bugfixing kind of issues. For help on configuration, please use the tomcat user list. Martin -Original Message- From: Kevin Conaway [mailto:[EMAIL PROTECTED]] Sent: 15 December 2002 17:33 To: [EMAIL PROTECTED] Subject: Apache+Tomcat+modjk with ~/public_html Is it possible to setup Apache/Tomcat/mod_jk to let users have servlets in the ~/public_html directory? I have tomcat setup so that if you call http://localhost:8080/~user it works, but it doesnt work through the main Apache server and mod_jk. Any thoughts? Kevin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL][TOMCAT5] plugins directory
8. Tomcat should work with no config file - using only JMX API calls to load it and configure a set of plugins ( profile ), using whatever class loader and layout the embeding application ( ant, etc ) wants. I've toyed with a thought along that line before. My train of thought was roughly, say you start Tomcat with a command line option for port or whatever. Then configure it using say JMX, then being able to save the modelled configuration out to a file that can be used in subsequent startups, or being possible to roll out on deployments or whatever. Or is that already possible (sorry I'm not up to speed with the admin app, I know it can create the server.xml, but were talking another level of config here right?) Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 15364] New: - The jsp:body action doesn't work as expected when used with the jsp:fallback action.
Seems Ryan Lubke makes Jan have a busy Friday afternoon :)... Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: using manager web application
The tomcat-dev list is for development questions/bugs please ask this question on the user list. Martin -Original Message- From: Eman Fattouh [mailto:[EMAIL PROTECTED]] Sent: 12 December 2002 10:16 To: [EMAIL PROTECTED] Subject: using manager web application dear all; i'm new in using Tomcat server, and i'm trying to deploy my applications on it. i tried to use manager web application through its web interface at http://myserver/manager/ i ftp my war file on server and try to install it but i couldn't it gives me connection time out i use it as follows: path: /var/tomcat4/webapps/prom config url:http://myserver/myfirsttrial war url: jar:file:/home/webdevtest/SourceWar/promo1.war!/ note that the war file exists on the server just in the location specified in war url field, and the folder i nedd the application to be unpacked to is prom and already created on server. i don't know what is the error in all what i mentioned above. please help me as soon as possible. Regards Eman -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Problem with Socket closing
I'm seeing something very similar on my system where we are running Tomcat 3.3. We basically got a URL object connection to our own server, and for some reason the URL class seems to do an unclean shutdown of the socket which results in socket write errors on the server. I don't understand why these errors gets reported to the logs, I would assume that a web server must expect clients to behave badly and disconnect without warning. I've learned to live with it rather than trying to fix it, but then again I'm on 3.3 you are on 4.1 and we might see different problems. Martin -Original Message- From: Greg Strobl [mailto:[EMAIL PROTECTED]] Sent: 12 December 2002 14:38 To: '[EMAIL PROTECTED]' Subject: Problem with Socket closing Hi, Tomcat 4.1.12 OS: W2K JRE: Sun 1.4.1_01 (Originally found using 1.4.0) I am seeing a problem with Tomcat closing a socket connection and having a write error. This happens with both SSL and regular sockets (the log example that is at the end show an SSL example.) I can reproduce the problem at times but sometimes that test case works (and the page renders as it should.) Our website sits on top of a data warehouse and I mostly experience the problem with the pages that have the longer queries. Does anybody know why this happens? Is there a fix? What can I do to try figure out what is causing the problem? I have turned up the debugging level on Tomcat (to 1) and that didn't produce much more information. I have added (println) statements to my code to see if there is a problem in it. It appears that my code always completes even when the socket connection is broken. Basically, I am at a point where I don't know what to try next. Here is the log output: 2002-12-11 17:07:28 ApplicationDispatcher[] Servlet.service() for servlet jsp threw exception org.apache.jasper.JasperException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Software caused connection abort: socket write error at org.apache.jasper.servlet.JspServletWrapper.service(JspServlet Wrapper.java:2 48) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet .java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(Applicat ionDispatcher. java:684) at org.apache.catalina.core.ApplicationDispatcher.doForward(Appli cationDispatch er.java:432) at org.apache.catalina.core.ApplicationDispatcher.forward(Applica tionDispatcher .java:356) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextI mpl.java:427) at org.apache.jsp.page_jsp._jspService(page_jsp.java:100) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServletWrapper.service(JspServlet Wrapper.java:2 04) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet .java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(Applicat ionDispatcher. java:684) at org.apache.catalina.core.ApplicationDispatcher.doForward(Appli cationDispatch er.java:432) at org.apache.catalina.core.ApplicationDispatcher.forward(Applica tionDispatcher .java:356) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextI mpl.java:427) at org.apache.jsp.page_jsp._jspService(page_jsp.java:116) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServletWrapper.service(JspServlet Wrapper.java:2 04) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet .java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardW rapperValve.ja va:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValv eContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipel ine.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardC ontextValve.ja va:191) at
RE: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
This is the soundest idea I've heard so far. Multiple distributions sounds like disaster area to me. I currently think it is hard enough for a new user to decide Tomcat3/Tomcat4.x/Tomcat5 when presented with the choices. If there in addition to that is Tomcat4 lite, Tomcat4 all Tomcat5 lite disaster, don't go there. I want one distribution with --enable --disable for source compilation and if I choose binary I can edit the config files (server.xml or whatever) to remove the options I don't need. Exactly like httpd (sort of)... M -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: 10 December 2002 10:35 To: Tomcat Developers List Subject: Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 ) It's exactly what SHOULD BE DONE in a modular approach of TC 5. A small core with essential functionalities, and a bunch of modules, which will live in modules dir or activated if module-xxx.xml found in conf directory of tomcat. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] More Content-Type problems with 304 responses (Tomcat3.3.1)
Hello...
I had a problem a while ago with If-Modified-Since responses 304 always
set the Content-Type to text/plain which consequently pollutes
web-caches that updates their cached entries with the new Content-Type.
E.g. if we request a GIF, the content type in the cache will the first
time be set to image/gif, if a subsequent If-Modified-Since request
makes the cache revalidate against it source Tomcat and tomcat says 304
Not Modified and Content-Type: text/plain, the cache will update its
cached entry to have the wrong content type.
The bug fix that time was to make sure Tomcat 3.3.1 does not set the
content type on a 304 response.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13662
This works as long as tomcat is not behind an Apache 1.3.27 server. That
apache server has got a DefaultType directive which is the type to use
for a requested resource does not have a type.
Well, the patch mentioned above just removed the type for 304 responses,
and consequently apache adds its default type, which arguably is wrong
in apache, but we can do a minor fix it in tomcat to get better
interoperability.
Basically it is fine with the http spec to set the Content-Type in a 304
response as long as it is the correct type (e.g. calling a gif a gif).
The patch submitted moves the check content type block to be before
the answer 304 response block. Which means we always set the content
type, even on a 304 response, but it will be the correct type.
Martin
--- StaticInterceptor.java-2002-11-29 Fri Nov 29 10:06:18 2002
+++ StaticInterceptor.java Tue Dec 10 11:18:12 2002
@@ -323,6 +323,22 @@
}
File file = new File( absPath );
+
+ // Moved to before 304 check since apache 1.3.27 always needs a
+ // Content-Type in order to not set its own DefaultType directive.
+ // It really should be possible to turn this directive off
+ // in apache, but you can't. However always setting the Content-Type
+ // even on a 304 is still compliant with the http spec. As long as
+ // the Content-Type is correct. Martin Algesten, November 2002.
+String mimeType=ctx.getMimeMap().getContentTypeFor(absPath);
+
+ if (mimeType == null) {
+ mimeType = text/plain;
+ }
+ if( debug0) log( Serving + absPath);
+
+ res.setContentType(mimeType);
+
// If we are included, the If-Modified-Since isn't for us.
if( ! res.isIncluded() ) {
MessageBytes imsMB=req.getMimeHeaders().getValue(If-Modified-Since);
@@ -343,14 +359,6 @@
}
if( debug0) log( After paranoic checks = + absPath);
-String mimeType=ctx.getMimeMap().getContentTypeFor(absPath);
-
- if (mimeType == null) {
- mimeType = text/plain;
- }
- if( debug0) log( Serving + absPath);
-
- res.setContentType(mimeType);
res.setContentLength((int)file.length());
setDateHeader(res, Last-Modified, file.lastModified());
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
-Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 10 December 2002 10:55 To: Tomcat Developers List Subject: Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 ) I really cannot believe I could agree with you on something ;-) Remy I might have strong opinions and seize every possible opportunity to ram them down others throats, but I am not completely unreasonable ;-) M -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] minimal JSR 154 only distribution
As an end user. I don't use the admin tool, don't know what it is. I do use both JSP and Servlets. M -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: 09 December 2002 14:06 To: Tomcat Developers List Subject: Re: [VOTE] minimal JSR 154 only distribution Jeanfrancois Arcand wrote: Jon Scott Stevens wrote: Create a separate minimal JSR 154 only distribution of Tomcat 4.x: +1 [] 0 [] -1 [X] -jon (1) Jasper is very a very small jar file. (2) The Admin Tool should go with the minimal distribution of Tomcat. We decided to include JMX in Tomcat distribution...what's the point having JMX and not the Admin Tool? Maybe JSP is not required by all Tomcat users, but I'm sure a lot of them like to have the Admin Tool . Not to pick on Jean Francois, but many times I have seen tomcat devs discuss what the users want or use when discussing features. I have no real idea what features tomcat users use or what features they want, other than anecdotal. Are there any facts behind the statement but I'm sure a lot of them like to have the Admin Tool.? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AW: euro character problem with tomcat compression Filter
And failing that perhaps cp1252 if you are a windowz kind of guy. I find this page helpful: http://czyborra.com/charsets/iso8859.html Martin On Thu, 2002-11-28 at 07:46, Torsten Fohrer wrote: sorry, iso-8859-15 -Ursprüngliche Nachricht- Von: Torsten Fohrer [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 28. November 2002 08:28 An: 'Tomcat Developers List' Betreff: AW: euro character problem with tomcat compression Filter try, to set the response encoding to 8559-15 cu Torsten -Ursprüngliche Nachricht- Von: Sergio [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 27. November 2002 21:18 An: 'Tomcat Developers List' Betreff: euro character problem with tomcat compression Filter Hí techies! I'm having problems adding the tomcat compression Filter version 4.0.3 to my webapp. Some characters (like euro symbol ) that are printed in my jsp page with a method which return a field of a MSSQLServer table, are printed with the '?' symbol. I've modified the CompressionFilter.java servlet and modified the code. Before the call of doFilter method I set the request to my encoding: request.setCharacterEncoding(iso-8859-1); chain.doFilter(request, response); But this also does not work. Any solution or idea ? Sorry for my English. Thanks, Sergio -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: tomcat-committers mailing list
Just for our non-committers peace of mind, what is the purpose of this list? What kind of information is it that we are to be denied or have delayed? Martin -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED]] Sent: 25 November 2002 17:41 To: [EMAIL PROTECTED] Subject: tomcat-committers mailing list Hi, The list was finally created. All active tomcat committers should subscribe. It is open to tomcat committers only, but as we discussed most information will be sent to tomcat-dev ( with some delay ). If some posting is intended to be non-public - please mark this explicitely ( or even better - don't send it in the first place :-). We also need volunteers to manage the list ( moderators ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ServletContext.getContext() still completely broken.
Are we going to release 4.1.15 without addressing this? This is a standard API call that currently DOES NOT WORK (or am I wrong, can anyone get hold of a foreign context from the ROOT context?) I've submitted a possible fix in BZ #13040 ... If you don't like it, then tell me why and I'll try patching it differently. I'm bored of maintaining my own patched up version locally. Surely a broken javax.servlet API call is serious enough to not be ignored? Martin
RE: ServletOutputStreamWrapper
Java tip: System.out.println( request.getInputStream().getClass().getName() ); and all shall be revealed. Martin -Original Message- From: Paul Hunnisett [mailto:develop;lombok.org.uk] Sent: 14 November 2002 20:05 To: Tomcat Developers List Subject: Re: ServletOutputStreamWrapper Thanks Craig, I'll take a look at that - hope fully it'll help me to move forward. I'm somewhat confused though - surely Tomcat must have subclasses of ServletInputStream and ServletOutputStream? What gets returned when an application call request.getInputStream() or response.getOutputStream? Paul Hunnisett www.lombok.org.uk -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: Servlet Spec interpretation FORM-based authentication
This seems another aspect of issue
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279 ... there are
some work in progress on that one. There's even a patch, check it out.
Martin
-Original Message-
From: Algirdas P. Veitas [mailto:aveitas;mail.allesta.com]
Sent: 12 November 2002 04:57
To: [EMAIL PROTECTED]
Subject: Servlet Spec interpretation FORM-based authentication
Folks,
I am running into an issue with FORM-based authentication
using 4.1.12 (and 4.0.4). It seems as if the implementation
is not in line with the 2.3 Servlet Specification. Specifically, the
Servlet Spec states:
SRV.12.5.3 Form Base Authentication
--snip--
J2EE.12.5.3.1 Login Form Notes
--snip--
If the form based login is invoked because of an HTTP request, the
original
request parameters must be preserved by the container for use if, on
successful authentication, it redirects the call to the requested
resource.
It seems as if the request parameters are not being preserved by the
container. After a successful login the container forwards me to the
target
URL (a JSP page). The JSP page executes the following code:
Enumeration params = request.getParameterNames();
while (params.hasMoreElements())
{
String paramKey = (String)params.nextElement();
String paramVal = request.getParameter(paramKey);
System.out.println(paramKey + = + paramKey); }
which I would expect to atleast see printed out:
j_username = some val
j_password = some val 2
but in fact these request parameters are not printed out and thus not
part of
the request.
A bit of digging in the source revealed that in the method
authenticate(HttpRequest,HttpResponse,LoginConfig)
of class org.apache.catalina.authenticator.FormAuthenticator, the code
is
executing HttpResponse.sendRedirect(String url) in order to forward the
user
to the appropriate page. A sendRedirect() will wipe out all of the
original
request parameters.
I think in order to preserve the parameters the sendRedirect() needs to
be
replaced by HttpRequest.getServletDispatcher().forward().
Has anyone else seen this behavior and is my claim valid?
Thanks,
Al
--
Open WebMail Project (http://openwebmail.org)
--
To unsubscribe, e-mail:
mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [Request] Commit the JNDIRealm patch
Getting discussions going in this list is like forcing water uphills. I've tried for a while now to get involved in sorting out problems that I've encountered. However it is quite hard when the patches I've attempted to make are dismissed without any kind of reasoning or discussion. Further I got something that looked like a hidden complaint about being here shouting about my favourite BZ numbers, when all I wanted to in the first place was to help out sorting them out myself. Any project needs managers and workers, this project seems to be lacking the first. There are obviously a lot of able hands like mine out there that wants to help out, but noone is coordinating or steering the efforts. In fact, no one even seems to be listening. Martin Fredrik Westermarck wrote: Jonathan Eric Miller wrote: I have a patch as well which I submitted back in June. I haven't received a response either. Well I guess you and I are the only ones using SSL to connect to our directory servers... It would be nice if someone reviewed our patches, merged and commited them, or atleast did start a discussion on the subject if the implementation could be improved or be done in a different and better way. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [VOTE] Proposed jspc refactoring
What about trying to argue for why an error page returns error code 200? Martin -Original Message- From: Remy Maucherat [mailto:remm;apache.org] Sent: 07 November 2002 16:10 To: Tomcat Developers List Subject: Re: [VOTE] Proposed jspc refactoring Costin Manolache wrote: To clarify - I agree jspc has a lot of broken options and features. My use case is: Removing the CLI or any other options is fine for me. I don't need jspc to compile or do any fancy thing - just compile JSPs to servlets and generate the web.xml fragment. Actually, I don't care about any use case of jspc (which is good as it's broken). I was just trying to help out fix bugs, and thought it would be better to try to provide user friendly tools (instead of bloated and broken ones). I'll focus on some other area of the code then. BTW, no matter how I look at it, the practice of generating servlets seems really ugly to me (of course, there are so many ugly things about JSPs, I guess it's only one of them). Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Remy?
Remy, since you were the one arguing against me, I would like you to reply to my two postings on the 30th of November, 13040, and ServletContext.getContext() and error code 200 when doing error-page. Sorry to hassle you, I know you've been away. Martin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: Tomcat 4.1.12 root context index.jsp bug
Did you make sure that the work director has been cleaned out? The compiled JSP will otherwise still sit around in there. Delete everything you find under CATALINA_BASE/work (or CATALINA_HOME/work). Martin -Original Message- From: Ian Hunter [mailto:ihunter;hunterweb.net] Sent: 05 November 2002 15:33 To: [EMAIL PROTECTED] Subject: Tomcat 4.1.12 root context index.jsp bug I have posted this in several different ways on the user list and had virtually no responses, and I believe it's a real live bug, so I'll post it here and then prepare to duck flames... Running Tomcat 4.1.12 with Sun JDK 1.4.1 on Win2K, if I change the root context to point someplace other than webapps/ROOT, I still get the default index.jsp if I request http://localhost:8080/index.jsp -- if that sounds sketchy and weird, get a load of this: I have also zipped up (removed the files from) webapps/ROOT completely (actually, webapps is completely empty), cleared my browser cache, etc. etc. and I still get the default index.jsp, but without the graphics (remember, the files are not anywhere on my drive). Further, I can successfully request any files OTHER than index.jsp (e.g. main.jsp, logon.jsp, etc. etc.) from the directory containing the new root context. Weird, eh? Is there a newer build I should try? I didn't see anything beyond 4.1.12 available. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Security threat with enabling invoker servlet in 4.1.12
The invoker servlet allows for anyone to call your servlets using their class names. This is not a problem as long as you are happy with that. In my case I have some internal servlets (used as a poor substitute for RMI) where I map the servlets to be under /internal/some.servlet and then protect /internal/* in my Apache web server in front of Tomcat. I don't use the invoker servlet since I want to declare exactly how my servlets are to be accessed. Martin Budi Kurniawan wrote: Hi, I've browsed the user list for this question but could not find the answer. Apologies if this is not the right question for this list. The release note in 4.1.12 says that the invoker servlet is turned off in the default web.xml for security reasons. However, in the examples app's web.xml the invoker is on. My questions are: 1. What security threat is that? 2. If it is not safe to turn it on in the default web.xml, is it safe to do so in the app web.xml? thx, budi -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: Bug with symbolic links in WEB-INF/lib/
This is not a bug, but a feature :).. The release notes tells more about it. Martin -Original Message- From: Frédérik Bilhaut [mailto:fbilhaut;wanadoo.fr] Sent: 01 November 2002 16:38 To: [EMAIL PROTECTED] Subject: Bug with symbolic links in WEB-INF/lib/ Hi ! I noticed a Tomcat bug that may be of interest for you developers. When using Tomcat 4.0.x, I used to set some symbolic links in my WEB-INF/lib directory. For example : WEB-INF/lib/mm.mysql.jar = /usr/java/lib/mm.mysql-xx.x/mm.mysql.jar But this won't work with Tomcat 4.1.12, which throws the following exception when deploying : java.lang.IllegalArgumentException: Invalid TLD resource path /WEB-INF/lib/mm.mysql.jar at org.apache.catalina.startup.ContextConfig.tldScanJar (ContextConfig.java:898) It took a while to figure out what happened, so maybe a note in RELEASE-NOTES would be usefull to many people :o) Best regards, -- Frédérik Bilhaut GREYC - Université de Caen http://www.info.unicaen.fr/~fbilhaut PS: Many thanks to Tomcat developers for such a great product PS': You'll find below the complete stack trace 2002-11-01 17:20:14 ContextConfig[/trouba] Exception processing JAR at resource path /WEB-INF/lib/mm.mysql-2.0.14-bin.jar javax.servlet.ServletException: Exception processing JAR at resource path /WEB-INF/lib/mm.mysql-2.0.14-bin.jar at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) - Root Cause - java.lang.IllegalArgumentException: Invalid TLD resource path /WEB-INF/lib/mm.mysql-2.0.14-bin.jar at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:898) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail:
Re: new Context
What do you mean creating a new Context? Can you give some code example? ... More parts of the stack trace might help as well. Martin Sasha Prikhod'ko wrote: Hi! sorry for stupid question... =) I'am creating a new Context but JSP applications don't work with exception: description: The server encountered an internal error () that prevented it from fulfilling this request. exception: javax.servlet.ServletException: org/apache/jasper/runtime/HttpJspBase etc... Thanks, Alex -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: new Context
In your server logs did you find any output along the lines of: WebappLoader[/GIS]: Deploying class repositories to work directory /home/martin/main/sites/mysite/var/tomcat/work/Standalone/localhost/GIS ContextConfig[/GIS]: Missing application web.xml, using defaults only StandardManager[/GIS]: Seeding random number generator class java.security.SecureRandom StandardManager[/GIS]: Seeding of random number generator has been completed StandardWrapper[/GIS:default]: Loading container servlet default StandardWrapper[/GIS:invoker]: Loading container servlet invoker Or are there any noises about /GIS? Martin Sasha Prikhod'ko wrote: suggest I did quite primitive thing: created a Context in the Tomcat administration tool server.xml: Context className=org.apache.catalina.core.StandardContext cachingAllowed=true charsetMapperClass=org.apache.catalina.util.CharsetMapper cookies=true crossContext=false debug=0 docBase=R:\GIS\jdocbase mapperClass=org.apache.catalina.core.StandardContextMapper path=/GIS privileged=false reloadable=false swallowOutput=false useNaming=true wrapperClass=org.apache.catalina.core.StandardWrapper /Context But jsp raises exceptions when opening on /GIS ! May be I don't understand right how to configure the java environment? Alex -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: production quality?
1. Tomcat should either not send any headers on a 304, or if it does then make sure that they do reflect the correct values for the requested object (e.g. not call a gif a text). 2. Not entirely sure here. Reading the HTTP/1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 It states: If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response. I suspect that is what we're seeing in mod_proxy. But I just realised that I have some reading to do, the stuff about weak and strong validator didn't make much sense to me... Martin jean-frederic clere wrote: Pier Fumagalli wrote: On 30/10/02 20:02, Martin Algesten [EMAIL PROTECTED] wrote: In a nutshell mod_proxy updates its cached entries with whatever new headers are given to it. E.g. first request comes into mod_proxy and it can't find the requested resource in its cache. It forwards on to my tomcat who responds with something like: HTTP/1.1 200 Content-Type: image/gif Content-Length: 12345 Second call comes into mod_proxy this time with an If-Modified-Since for the same resource. mod_proxy needs to revalidate its cached entry against tomcat and does an If-Modifed-Since against tomcat and tomcat answers: HTTP/1.1 304 Content-Type: text/html Content-Length: 0 At this point mod_proxy updates it's cached entry and ends up with a gif that has got a Content-Type set to text/html. Further requests to mod_proxy without If-Modified-Since results in GIFs with strange content types. Thank god for IE not trusting the content type :) Nope, that's not it, but it's a good catch. We don't keep proxied content cached... Thanks a lot for the clarification... If I got it right there are 2 errors: 1 - Tomcat should not send a Content-Type nor Content-Length. 2 - mod_proxy should complain because we are sending garbages or ignore the invalid headers. Pier (gone diggin' mirrors) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: production quality?
Yup.. as I said, generally content-type changes might be ok. And yes I have reported it as a bug. Martin jean-frederic clere wrote: Martin Algesten wrote: I don't see how chaning the Content-Type can be right in this scenario (yes, generally content-type changes might be ok), can you explain. If I understood this correctly we are asking Tomcat if a specific object has changed (If-Modified-Since), and any response should surely be true about the resource we're asking about. E.g. if we're asking if a certain gif file has changed since yesterday, then tomcat tells us that it is unchanged content wise, but meta-wise it is no longer a gif, but an html document?! Yes, in the scenario that is a bug. So report it as a bug. But think of an ISO image incorrectly transferted as text/html due to _bad_ mime type configuration, would not it be nice to just change the mime type and not resend the whole file? Martin jean-frederic clere wrote: Martin Algesten wrote: 1. Tomcat should either not send any headers on a 304, or if it does then make sure that they do reflect the correct values for the requested object (e.g. not call a gif a text). Changing a Content-Type is legitimate, but changing the Content-Length is probably not. But I do not think that Tomcat has to change the Content-Type. 2. Not entirely sure here. Reading the HTTP/1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 It states: If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response. I suspect that is what we're seeing in mod_proxy. But I just realised that I have some reading to do, the stuff about weak and strong validator didn't make much sense to me... It changes the Content-Type and I think that is OK. Martin jean-frederic clere wrote: Pier Fumagalli wrote: On 30/10/02 20:02, Martin Algesten [EMAIL PROTECTED] wrote: In a nutshell mod_proxy updates its cached entries with whatever new headers are given to it. E.g. first request comes into mod_proxy and it can't find the requested resource in its cache. It forwards on to my tomcat who responds with something like: HTTP/1.1 200 Content-Type: image/gif Content-Length: 12345 Second call comes into mod_proxy this time with an If-Modified-Since for the same resource. mod_proxy needs to revalidate its cached entry against tomcat and does an If-Modifed-Since against tomcat and tomcat answers: HTTP/1.1 304 Content-Type: text/html Content-Length: 0 At this point mod_proxy updates it's cached entry and ends up with a gif that has got a Content-Type set to text/html. Further requests to mod_proxy without If-Modified-Since results in GIFs with strange content types. Thank god for IE not trusting the content type :) Nope, that's not it, but it's a good catch. We don't keep proxied content cached... Thanks a lot for the clarification... If I got it right there are 2 errors: 1 - Tomcat should not send a Content-Type nor Content-Length. 2 - mod_proxy should complain because we are sending garbages or ignore the invalid headers. Pier (gone diggin' mirrors) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Tomcat 4.1 no go for my production env.
Just following up on my thoughts wether Tomcat 4.1 is ready for production or not. Yesterday and today I tried to roll one preview site out on our existing server infrastructure... and so far it created complete havoc. Oddly enough I'm running a Coda replicated file system on my production servers and that is where the Tomcat home is. Now Coda is a semi-dodgy piece of software (it's a love-hate thing) and you need to be gentle with it. Tomcat 3.3.1 is fine running in this way, but 4.1 so far crashed the whole coda file system both yesterday and today. This is not a complaint about Tomcat 4, rather an observation that it doesn't seem to behave in this environment. I will start investigating why this is. My suspicion there is something about Coda having AFS file semantics rather than unix or windows ones. Martin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Status-Line with no Reason-Phrase
It seems to me that the Coyote JK 2 connector doesn't set the Reason-Phrase for the responses, is this right? I know that you don't have to do this according to the HTTP/1.1 spec. However once again my dear mod_proxy isn't to happy about a status line saying: HTTP/1.1 200 (the trailing space is significant). In this situation mod_proxy inserts an extra line break in the header after the status line but before the headers ending up with something like: HTTP/1.1 200 Date: Thu, 31 Oct 2002 14:58:28 GMT Server: Apache/1.3.26 (Unix) mod_jk/1.1.0 DAV/1.0.3 mod_ssl/2.8.10 OpenSSL/0.9.6g Set-Cookie: JSESSIONID=1B937C37372FC2947895B82B361D8B0E; Path=/ Content-Type: text/html; charset=utf-8 X-Cache: MISS from rhubarb.salad.taglab.com Transfer-Encoding: chunked And I can tell you that doesn't look pretty in the browser :)... I know this is really not Coyote's problem, this is a bug in mod_proxy. According to the HTTP/1.1 spec it might even be more correct to send the trailing space than without, however that is exactly what triggers the bug... If I despite this would like Coyote JK 2 to provide the Reason-Phrase... Would the correct place to do so be in the org.apache.coyote.Response using org.apache.tomcat.util.http.HttpMessages class? Martin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: production quality?
I don't see how chaning the Content-Type can be right in this scenario (yes, generally content-type changes might be ok), can you explain. If I understood this correctly we are asking Tomcat if a specific object has changed (If-Modified-Since), and any response should surely be true about the resource we're asking about. E.g. if we're asking if a certain gif file has changed since yesterday, then tomcat tells us that it is unchanged content wise, but meta-wise it is no longer a gif, but an html document?! Martin jean-frederic clere wrote: Martin Algesten wrote: 1. Tomcat should either not send any headers on a 304, or if it does then make sure that they do reflect the correct values for the requested object (e.g. not call a gif a text). Changing a Content-Type is legitimate, but changing the Content-Length is probably not. But I do not think that Tomcat has to change the Content-Type. 2. Not entirely sure here. Reading the HTTP/1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 It states: If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response. I suspect that is what we're seeing in mod_proxy. But I just realised that I have some reading to do, the stuff about weak and strong validator didn't make much sense to me... It changes the Content-Type and I think that is OK. Martin jean-frederic clere wrote: Pier Fumagalli wrote: On 30/10/02 20:02, Martin Algesten [EMAIL PROTECTED] wrote: In a nutshell mod_proxy updates its cached entries with whatever new headers are given to it. E.g. first request comes into mod_proxy and it can't find the requested resource in its cache. It forwards on to my tomcat who responds with something like: HTTP/1.1 200 Content-Type: image/gif Content-Length: 12345 Second call comes into mod_proxy this time with an If-Modified-Since for the same resource. mod_proxy needs to revalidate its cached entry against tomcat and does an If-Modifed-Since against tomcat and tomcat answers: HTTP/1.1 304 Content-Type: text/html Content-Length: 0 At this point mod_proxy updates it's cached entry and ends up with a gif that has got a Content-Type set to text/html. Further requests to mod_proxy without If-Modified-Since results in GIFs with strange content types. Thank god for IE not trusting the content type :) Nope, that's not it, but it's a good catch. We don't keep proxied content cached... Thanks a lot for the clarification... If I got it right there are 2 errors: 1 - Tomcat should not send a Content-Type nor Content-Length. 2 - mod_proxy should complain because we are sending garbages or ignore the invalid headers. Pier (gone diggin' mirrors) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
production quality?
Hi all, Just some thoughts. I've been using the 3.3.1 release for quite some time in a mod_jk/apache/linux kind of setup and all was fine. Though a couple of weeks ago I felt a need to start looking at new versions of all my API's/products in order to make sure I stay on top of things and don't end up with unsupported versions. What do we mean with production quality? According to the Tomcat project home page, 4.1.12 is a production quality release, however using it in real life makes me question the usefulness of such status. I've been monitoring this list and also tried to contribute by discussing/submitting patches for the bugs I've encountered. I don't have an issue with how long it takes to resolve these issues, after all we are all doing this for fun (more or less ;) ). However I do think we have a responsibility in what signals we're sending regarding how useful a release really is. The current 4.1.12 release have some quite nasty issues that in some production setups makes it more or less useless. In my opinion the most nasty issues are those that directly breaks internet standards and the core API (10373, 13846, 13040). What about quality control? Well, the bugzilla do allow for a Severity, Priority classification. Perhaps we should start classifying bugs more actively using these switches. This could be combined with a policy that we don't make a release before certain levels of issues are all resolved? I also get a feeling that we as developers are somewhat in the wrong position to label things as production quality. The watchdog tests are all very well, but can never replace real life scenarios. Perhaps we need a new label such as release candidate? Perhaps we should be more in the spirit of other open source projects, (OpenSSL and Mozilla comes to mind), where the release cycle seems to more involve end users and have a more cautious labelling of releases. This is not intended as criticism of anyone. After all Tomcat is a fantastic project with fantastic people contributing. Good work all! Martin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: production quality?
Hmm... perhaps not drop it after all. I had a think about it and I still would argue that the amount of developers or the speed of turning out fixes is not the issue. As I said before, we are all doing this more or less for fun. Taking on board that its all about expectations and that you need to test your software before deploying it and that 4.1.12 can be definitelly considered production quality for certain uses. There is still a big difference between 3.3.1 and 4.1.12, the former seems to be a more solid piece of software than the latter, and still they both enjoy the same status on the Tomcat home page. Isn't just the sheer amount of bug reports an argument in my direction? Martin Remy Maucherat wrote: Martin Algesten wrote: Hi all, Just some thoughts. I've been using the 3.3.1 release for quite some time in a mod_jk/apache/linux kind of setup and all was fine. Though a couple of weeks ago I felt a need to start looking at new versions of all my API's/products in order to make sure I stay on top of things and don't end up with unsupported versions. What do we mean with production quality? According to the Tomcat project home page, 4.1.12 is a production quality release, however using it in real life makes me question the usefulness of such status. I've been monitoring this list and also tried to contribute by discussing/submitting patches for the bugs I've encountered. I don't have an issue with how long it takes to resolve these issues, after all we are all doing this for fun (more or less ;) ). However I do think we have a responsibility in what signals we're sending regarding how useful a release really is. The current 4.1.12 release have some quite nasty issues that in some production setups makes it more or less useless. In my opinion the most nasty issues are those that directly breaks internet standards and the core API (10373, 13846, 13040). 10373: I'm not convinced by the validity of the report. 13040: The spec is IMO not implementable, and most of the patches submitted were wrong. Hence, the issue is not fixed. Sorry. 13846: This is a minor bug (IMHO) which will need a rather risky refactoring of the headers handling to fix, hence I decided to postpone fixing it. Unfortunaltely, there's simply not enough developers to handle the amount of bug reports being filed. If the report is not crystal clear or is not easy to reproduce and investigate, then no one will look into it. The only way we could improve on this is that more people like you stepped in and helped fix bugs and investigate issues. Unfortunately, fixing bugs is not fun, and it doesn't happen very often (people prefer to complain about their favorite BZ report instead) :-( Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: production quality?
I'm dropping my argument about labelling now. It will probably not lead anywhere anyway. Martin Remy Maucherat wrote: Martin Algesten wrote: Hi all, Just some thoughts. I've been using the 3.3.1 release for quite some time in a mod_jk/apache/linux kind of setup and all was fine. Though a couple of weeks ago I felt a need to start looking at new versions of all my API's/products in order to make sure I stay on top of things and don't end up with unsupported versions. What do we mean with production quality? According to the Tomcat project home page, 4.1.12 is a production quality release, however using it in real life makes me question the usefulness of such status. I've been monitoring this list and also tried to contribute by discussing/submitting patches for the bugs I've encountered. I don't have an issue with how long it takes to resolve these issues, after all we are all doing this for fun (more or less ;) ). However I do think we have a responsibility in what signals we're sending regarding how useful a release really is. The current 4.1.12 release have some quite nasty issues that in some production setups makes it more or less useless. In my opinion the most nasty issues are those that directly breaks internet standards and the core API (10373, 13846, 13040). 10373: I'm not convinced by the validity of the report. 13040: The spec is IMO not implementable, and most of the patches submitted were wrong. Hence, the issue is not fixed. Sorry. 13846: This is a minor bug (IMHO) which will need a rather risky refactoring of the headers handling to fix, hence I decided to postpone fixing it. Unfortunaltely, there's simply not enough developers to handle the amount of bug reports being filed. If the report is not crystal clear or is not easy to reproduce and investigate, then no one will look into it. The only way we could improve on this is that more people like you stepped in and helped fix bugs and investigate issues. Unfortunately, fixing bugs is not fun, and it doesn't happen very often (people prefer to complain about their favorite BZ report instead) :-( Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
error code 200 when doing error-page
It can't be correct to reset the error code to 200 when say a 404 have happened. A) Web caches, search engines etc will get confused by this. If a page get spidered by say Google and the returned response code is a 404, then the page will not be part of the index, which is correct, the opposite is silly. A broken page should of course be indicated as broken and a missing page should be indicated as missing, e.g. a 500 is a 500 and a 404 is a 404 and not 200. B) Generally around the web there seems to be a prescedence for not returning 200 when pages that don't exist are asked for: $ curl -s -I http://www.microsoft.com/foo | grep HTTP HTTP/1.1 404 $ curl -s -I http://java.sun.com/foo | grep HTTP HTTP/1.1 404 Not Found $ curl -s -I http://www.oracle.com/foo | grep HTTP HTTP/1.1 404 Not Found $ curl -s -I http://jakarta.apache.org/foo | grep HTTP HTTP/1.1 404 Not Found What is the argument for returning 200? Regards, Martin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: production quality?
Hello again, The quote helps pointing out one important thing It's all a matter of expectations. That's just another way of twisting my point, what we're dealing with here is expectation management. Apache Tomcat has reached a state where it is deployed widely around the world in live environments. The Apache name is for most people synonymous with quality, and on top of that we got Sun Java's endorsment of Tomcat by virtue of J2EE. This means that wether we like it or not Apache Tomcat does raise whole lot of expectation. These expectations are a form of trust, which is a nice thing and that we need to responsibly care for, rather than brushing them under the carpet with a it's your problem to test your software before going to production. Making sure known bugs are addressed before releasing a new version and perhaps being more explicit about what issues a release might have, is only acting responsibly towards the trust people have in what we do. Martin Shapira, Yoav wrote: Hi, Every now and then a message along those lines comes up. I've seen it in all the open sources projects I've contributed to, and (what does that say? I have too much free time? ;)) these are many. I will quote a response, not written by me, that I think is a perfect way to look at the process. I hope Will won't mind being quoted ;) From: Milt Epstein [EMAIL PROTECTED] Sent: Friday, August 23, 2002 10:11 AM I mean, I understand (and sympathize with what you're saying), but I also understand the position of those who want to wait until there's release-quality code available. I mean, what will the typical manager say after the production system breaks down and you tell them that you went with beta-quality code instead of release-quality code. It's all a matter of expectations. I find that most people want the system to work and aren't really caught up on release numbers and labels. Now, through probably painful experience, people have lower expectations of 1.0 code, Beta code, etc. They pretty much expect it to fail in some, perhaps critical, way. They may use the label as an indicator whether the code is worth testing. But the real problem is not necessarily whether its Beta or Release quality, it is the testing facilities available to the consumers. If you had a deployed application and a solid, thorough feature and load test suite of your application, then it shouldn't matter what the back end code is labeled. If your test is complete and robust enough and thus confirms that your application will behave as designed, then Release or Beta are irrelevant. The dark side of this is that folks will say Well, gee I don't have to 'test' release code, it's already tested!. To wit everybody falls over on the floor in hysterics. The acceptance process for the software should be the same whether Beta or Release. No matter how thorough the testing by the folks developing the application, no doubt they have NOT tested their software on YOUR application with YOUR load conditions on YOUR hardware. And it should go without saying that this applies to any major infrastructure component in your application, not just Tomcat. Don't just blindly upgrade your system to Solaris 9, Oracle 9i and new Firewall software and then throw the application live because it's all release quality software. There are disclaimers in those licenses for a reason. Caveat Emptor and all that. Regards, Will Hartung ([EMAIL PROTECTED]) Yoav Shapira Millennium ChemInformatics -Original Message- From: Martin Algesten [mailto:puckman;taglab.com] Sent: Wednesday, October 30, 2002 6:19 AM To: [EMAIL PROTECTED] Subject: production quality? Hi all, Just some thoughts. I've been using the 3.3.1 release for quite some time in a mod_jk/apache/linux kind of setup and all was fine. Though a couple of weeks ago I felt a need to start looking at new versions of all my API's/products in order to make sure I stay on top of things and don't end up with unsupported versions. What do we mean with production quality? According to the Tomcat project home page, 4.1.12 is a production quality release, however using it in real life makes me question the usefulness of such status. I've been monitoring this list and also tried to contribute by discussing/submitting patches for the bugs I've encountered. I don't have an issue with how long it takes to resolve these issues, after all we are all doing this for fun (more or less ;) ). However I do think we have a responsibility in what signals we're sending regarding how useful a release really is. The current 4.1.12 release have some quite nasty issues that in some production setups makes it more or less useless. In my opinion the most nasty issues are those that directly breaks internet standards and the core API (10373, 13846, 13040). What about quality control? Well, the bugzilla do allow for a Severity, Priority
Re: production quality?
The reports I referred to were just the ones affecting me in my setup, and my point was not about their validity, rather just an overall feeling from using this particular software. I have not tested other containers for spec compatibility, I can't claim to have even tested this one. I have a number of smaller websites with various amounts of traffic running on Tomcat 3.3.1, and yes the uptime is remarkably good. Software is never perfect and any setup will work differently. I don't expect to be able to change my 3.3.1 to 4.1.12 and have everything working without any effort. Different live scenarios always implies different workarounds/tradeoffs. So in that sense you're either using a particular subset of functionality that works in your live scenario or you've worked around any issues that you encountered. Regards, Martin Glenn Nielsen wrote: Martin Algesten wrote: Hi all, Just some thoughts. I've been using the 3.3.1 release for quite some time in a mod_jk/apache/linux kind of setup and all was fine. Though a couple of weeks ago I felt a need to start looking at new versions of all my API's/products in order to make sure I stay on top of things and don't end up with unsupported versions. What do we mean with production quality? According to the Tomcat project home page, 4.1.12 is a production quality release, however using it in real life makes me question the usefulness of such status. I've been monitoring this list and also tried to contribute by discussing/submitting patches for the bugs I've encountered. I don't have an issue with how long it takes to resolve these issues, after all we are all doing this for fun (more or less ;) ). However I do think we have a responsibility in what signals we're sending regarding how useful a release really is. The current 4.1.12 release have some quite nasty issues that in some production setups makes it more or less useless. In my opinion the most nasty issues are those that directly breaks internet standards and the core API (10373, 13846, 13040). I quickly reviewed the three bug reports above. All three seem to be related to spec compliance and interpretation of the spec. Just curious, have you done the same level of spec compliance testing with other conatiners? How well do they comply? For me use Tomcat 4.1 is production quality. I use it with Apache mod_jk/AJP on a medium volume site with 20-30K tomcat requests per day with peaks of over 5000 tomcat requests per hour. And I get uptimes of over four weeks. Regards, Glenn -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
13040, and ServletContext.getContext()
We've agreed that the spec needs clarifying here. Unfortunatelly we can not wait around for that since the current API is completely broken. A ServletContext.getContext from the ROOT context currently ALWAYS returns the ROOT context, no matter what. It is therefore impossible to programatically forward/include anything across the webapps boundaries. We need to do something: My proposal is either: A) Ignore getContext() where the incomming uri is along the lines of /store/common/something and what the caller actually wants is /store. (Patch submitted in bug 13040 for that). or B) Remove the optimisation completely. But I'm open to suggestions and I'm happy to implement another patch if anyone feels it needs to be done differently. As long as we don't leave the API broken. Martin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: production quality?
In a nutshell mod_proxy updates its cached entries with whatever new headers are given to it. E.g. first request comes into mod_proxy and it can't find the requested resource in its cache. It forwards on to my tomcat who responds with something like: HTTP/1.1 200 Content-Type: image/gif Content-Length: 12345 Second call comes into mod_proxy this time with an If-Modified-Since for the same resource. mod_proxy needs to revalidate its cached entry against tomcat and does an If-Modifed-Since against tomcat and tomcat answers: HTTP/1.1 304 Content-Type: text/html Content-Length: 0 At this point mod_proxy updates it's cached entry and ends up with a gif that has got a Content-Type set to text/html. Further requests to mod_proxy without If-Modified-Since results in GIFs with strange content types. Thank god for IE not trusting the content type :) Bug 13846 has my curl detective work in it... M Pier Fumagalli wrote: On 30/10/02 6:06 pm, Martin Algesten [EMAIL PROTECTED] wrote: An incorrect If-Modified-Since response seems to shag mod_proxy. Now I don't know how widely used mod_proxy is, or if perhaps this should be fixed there instead. However I am concerned about this and as I pointed out I am happy to look into it myself, however I would appreciate a hint of what to look at. You mention a header refactoring, elaborate? Could it be what we are observing on http://nagoya.apache.org/eyebrowse when we pass stuff in the backend on port 8080? What would be the outcome of this? (I mean you know any way in which I can find out if this is the bug we're seeing) Pier -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
