Re: Double Slash Support in Tomcat 9.0.27
Hi Mark, Please find the snippet from web.xml default org.apache.catalina.servlets.DefaultServlet debug 0 listings false 1 jsp org.apache.jasper.servlet.JspServlet fork false xpoweredBy false 3 default / jsp *.jsp *.jspx PatternTemplateLaunchServlet PatternTemplateLaunchServlet MyReportsLaunchServlet MyReportsLaunchServlet PatternTemplateLaunchServlet /patterntemplatelaunch MyReportsLaunchServlet /MyReportsLaunchServlet Please let me know if you need anyother details from our side. On Mon, Dec 2, 2019 at 3:07 AM Mark Thomas wrote: > On 01/12/2019 07:11, Kushagra Bindal wrote: > > Hi Manna/Mark, > > > > Below are the sample URL which we are passing to Tomcat. > > > > http://backend_tomcat:8080//sdm/restcall)(.*)/file_uploads > > http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck > > > > As from the above example you can see that // location may vary case by > > case. > > > > So, you guys have a probable solution to handle such situation, then > please > > do let me know. > > Tomcat is simply going to normalize those to single '/'. The application > should be fine with that. > > To repeat my previous request: > Can you provide more details such as: > - an example request URI > *and* > - the for the servlet you expect it to match to > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Regards, Kushagra Bindal +91-9013792807
Re: Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information
On 29/11/2019 11:48, Klein, Carsten wrote: > However, we are developing Ajax-driven > B2B client applications, which terminate / end the session when they > detect loss of authentication. Technically, these apps periodically send > keep-alive messages to the server (in order to keep the session alive, > since with Ajax the server is only queried when data must be loaded or > updated). When such a keep-alive fails with a 401 code, the session has > gone and the application terminates (so, the Admin is able to > 'disconnect' clients by invalidating their session). Currently, this > happens for all active clients after reloading the context or restarting > Tomcat :-( > >>> That may be a security thing, but if, for example, passwords stored in >>> the GenericPrincipal instance are not serialized, I don't see a security >>> problem with persisting the session's principal. >> >> User names and passwords are generally viewed as more sensitive that the >> Principal object which is generally viewed as more sensitive than the >> session ID. >> >> Where users draw the line between what is acceptable and unacceptable is >> going to vary. > > I'm with you. And likely our setup is special in a way. However, I've > rarely seen that you have to re-enter credentials in a professional web > application like Google or Facebook, for example. Yes. But if those apps were running on Tomcat I doubt that a) they'd be running on a single instance and b) they'd be using Tomcat's in memory session management. > In some of our projects we use self-written replacements for Tomcat's > GenericPrincipal (ours is serializable, I know yours in version 8 or 8.5 > is too, but on Ubuntu 14.04 we're still on Tomcat 7), StandardSession > and StandardManager. However, it's some work to keep these classes up to > date for new versions of Tomcat. So my basic question was, couldn't > Tomcat do that for us? As an option, disabled by default I don't see why not. > I understand that different users have different requirements and for > some, persisting a Principal (likely including a password) on disk for > some seconds during a reload is really not acceptable. BTW, why ever do > you save passwords?? Good question. I suspect it might be related to single-sign-on but I'd need to do some svn archaeology to try and answer that more definitively. > So, the best solution to that would be to make this a configurable > option of the Manager, named 'persistPrincipal', for example. Maybe I > could even help developing that (if I had some time). Agreed. A good place to start would be to open a Bugzilla enhancement request against 9.0.x (we always develop for the latest version first and then back-port). After that, we accept patches in Bugzilla or Pull Requests at GitHub. Expect a fair amount a feedback on your first version (my first patch needed to be completely re-written) but a couple of tips to reduce the rework: - enable checkstyle and make sure there are no errors when building - generally, follow the style of the code you are editing (the Tomcat code style is not always consistent) Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Async file upload server has 33% less throughput compared to the sync version
On 01/12/2019 02:17, Behrang Saeedzadeh wrote: > Any ideas what am I missing here? Async provides scalability, not raw performance. You haven't written a async file upload servlet. That would require non-blocking I/O and look more like this: https://github.com/apache/tomcat/blob/master/webapps/examples/WEB-INF/classes/nonblocking/ByteCounter.java Step back from your code for a second. The async version does exactly the same thing as the sync version apart from it does a bunch of *extra* stuff (creating the Runnable and dispatching it to a different thread). Why would you expect the code that does extra stuff, to take less time when it does more? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
On 01/12/2019 07:11, Kushagra Bindal wrote: > Hi Manna/Mark, > > Below are the sample URL which we are passing to Tomcat. > > http://backend_tomcat:8080//sdm/restcall)(.*)/file_uploads > http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck > > As from the above example you can see that // location may vary case by > case. > > So, you guys have a probable solution to handle such situation, then please > do let me know. Tomcat is simply going to normalize those to single '/'. The application should be fine with that. To repeat my previous request: Can you provide more details such as: - an example request URI *and* - the for the servlet you expect it to match to Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 http2 upload failed with big file.
On 01/12/2019 17:03, Arief Hasani wrote: > Hi, > Strangely I can not upload big file (~20Mb) when using http2 using curl with > unexpected EOF error, whereas the upload was successful when forcing curl to > use http1.1 protocol so I assume code and configuration should be correctI am > using tomcat 9.0.29 Which version of curl? I recommend you read through this issue: https://bz.apache.org/bugzilla/show_bug.cgi?id=63948 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 9 http2 upload failed with big file.
Hi, Strangely I can not upload big file (~20Mb) when using http2 using curl with unexpected EOF error, whereas the upload was successful when forcing curl to use http1.1 protocol so I assume code and configuration should be correctI am using tomcat 9.0.29 Kind regardsHasani
