Re: IP issues
Remy Maucherat wrote: Jason Hunter wrote: I do have a CLA on file. Aren't members required to? :) That code donation happened while Tomcat was still Sun internal and I was helping Sun as a contractor. Those were the good old days before I was burdened with the knowledge about IP rights that I've since acquired (as has Remy obviously). It was even before Jakarta. I'm still fine with the donation. Technically the code wouldn't be covered under the CLA since I didn't take action to donate the code to Apache; it just came over from Sun in the bundle. I'm happy to go on record here as giving it a formal stamp of approval, with the one caveat that I'd like it to retain attribution since the classes have a life of their own separately. I believe Apache has policies for including code with attribution. Our own license requires attribution, so we'd better. :) Jumping back to the thread I started since I'm back from vacation ... And here I thought we put the thread to rest. The comment includes Used by Sun Microsystems with permission.. I don't see any explicit permission for this item Please see my email above there I answer this. (so AFAIK, we're not covered if we mention we need Sun's permission for that code), Correct. But please see above. nor see why we need an exception for such a such a small amount of code. You need an exception because (a) the code was included from a third party codebase and (b) a lot of research and testing went into compiling the map used by the mapper. I can easily add an @author tag for you in the relevant files, but the comment currently creates a legal doubt. As I wrote in my email and for the archived record, I want the classes to have the recognition that is expected when Apache includes code from a third party library that's under a license that requires attribution (just like Apache's). Note: Many companies and individuals donated more than these 10 lines of code, Yes, and I too donated plenty of code to the Tomcat codebase. But these classes I donated (to Sun at the time) with attribution because they were from a separate, pre-existing codebase with a life of its own. If you write a book and include a paragraph from someone else's book with permission, you mention it and you point at the source of the original work. You don't just say, Written by author X you say, Written by author X as part of book Y, published by Z. That's why the attribution I put on those classes includes the who, what, and where. I see it as the ethical thing to do. -jh- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP issues
I think it would be rude to remove the comments about where the source files originated, as they were developed apart from Apache and have a life on their own apart from Apache. Attribution is fair and proper. However I did grant permission for Sun (and of course Apache) to license the code under the Apache license. -jh- Remy Maucherat wrote: Hi, There are apparently a few licensing issues with some files in the Tomcat CVS: jakarta-tomcat-5.0.28-src/jakarta-tomcat-catalina/catalina/src /share/org/apache/catalina/util/CharsetMapper.java 18: * This class is based on a class originally written by Jason Hunter 19: * [EMAIL PROTECTED] as part of the book Java Servlet Programming 20: * (O'Reilly). See http://www.servlets.com/book for more information. 21: * Used by Sun Microsystems with permission. 22: */ 23: 24: package org.apache.catalina.util; jakarta-tomcat-5.0.28-src/jakarta-tomcat-catalina/webapps/admi n/images/Context.gif 4: ?ycga???wHIL!?OCopyright 2000 by Sun Microsystems, Inc. All Rights Reserved. 5: JLF GR Ver 1.0 jakarta-tomcat-5.0.28-src/jakarta-tomcat-catalina/webapps/admi n/images/Host.gif 2: !?OCopyright 2000 by Sun Microsystems, Inc. All Rights Reserved. jakarta-tomcat-5.0.28-src/jakarta-tomcat-connectors/util/java/ org/apache/tomcat/util/http/LocaleToCharsetMap.java 19: * This class was originally written by Jason Hunter [EMAIL PROTECTED] 20: * as part of the book Java Servlet Programming (O'Reilly). 21: * See http://www.servlets.com/book for more information. 22: * Used by Sun Microsystems with permission. Fixing the GIFs should be easy. How about the two Java files ? I would need an answer from Jason and Craig to see if I can safely remove the comments (otherwise we would have to reimplement these, right ?). Thanks, Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP issues
I do have a CLA on file. Aren't members required to? :) That code donation happened while Tomcat was still Sun internal and I was helping Sun as a contractor. Those were the good old days before I was burdened with the knowledge about IP rights that I've since acquired (as has Remy obviously). It was even before Jakarta. I'm still fine with the donation. Technically the code wouldn't be covered under the CLA since I didn't take action to donate the code to Apache; it just came over from Sun in the bundle. I'm happy to go on record here as giving it a formal stamp of approval, with the one caveat that I'd like it to retain attribution since the classes have a life of their own separately. I believe Apache has policies for including code with attribution. Our own license requires attribution, so we'd better. :) -jh- Henri Yandell wrote: (this is based on assumptions, so let me know if they are wrong Jason) I must admit that I lack the experience to be sure of the correct action here. The image copyrights are easy; things need to be copyright to the ASF, not to Sun. So they need fixing somehow. Jason's code is harder. It doesn't say that it's copyrighted to Jason, just that it's originally from classes by him. As the code in Tomcat is copyright to the ASF, there's no reason why we couldn't remove the comments apart from the politeness aspect that Jason raises. The code isn't licenced to the ASF, it's donated to the ASF and now owned by the ASF (for this instance, Jason owns a duplicate instance). Not knowing the whole story, the whole question is whether we actually own that code or if it was licensed to Sun and then they donated it to Apache, something they did not have the right to do. Does Jason have a CLA, and if not, would we need one? I think we should remove the Sun permission line; it's not important to the existence in Tomcat. Keeping the rest of the comment seems fine to me, provided we're sure we own the code. Hen On Wed, 22 Dec 2004 14:12:43 -0800, Jason Hunter [EMAIL PROTECTED] wrote: I think it would be rude to remove the comments about where the source files originated, as they were developed apart from Apache and have a life on their own apart from Apache. Attribution is fair and proper. However I did grant permission for Sun (and of course Apache) to license the code under the Apache license. -jh- Remy Maucherat wrote: Hi, There are apparently a few licensing issues with some files in the Tomcat CVS: jakarta-tomcat-5.0.28-src/jakarta-tomcat-catalina/catalina/src /share/org/apache/catalina/util/CharsetMapper.java 18: * This class is based on a class originally written by Jason Hunter 19: * [EMAIL PROTECTED] as part of the book Java Servlet Programming 20: * (O'Reilly). See http://www.servlets.com/book for more information. 21: * Used by Sun Microsystems with permission. 22: */ 23: 24: package org.apache.catalina.util; jakarta-tomcat-5.0.28-src/jakarta-tomcat-catalina/webapps/admi n/images/Context.gif 4: ?ycga???wHIL!?OCopyright 2000 by Sun Microsystems, Inc. All Rights Reserved. 5: JLF GR Ver 1.0 jakarta-tomcat-5.0.28-src/jakarta-tomcat-catalina/webapps/admi n/images/Host.gif 2: !?OCopyright 2000 by Sun Microsystems, Inc. All Rights Reserved. jakarta-tomcat-5.0.28-src/jakarta-tomcat-connectors/util/java/ org/apache/tomcat/util/http/LocaleToCharsetMap.java 19: * This class was originally written by Jason Hunter [EMAIL PROTECTED] 20: * as part of the book Java Servlet Programming (O'Reilly). 21: * See http://www.servlets.com/book for more information. 22: * Used by Sun Microsystems with permission. Fixing the GIFs should be easy. How about the two Java files ? I would need an answer from Jason and Craig to see if I can safely remove the comments (otherwise we would have to reimplement these, right ?). Thanks, Rémy - 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-servletapi-5/jsr154/src/share/javax/servlet/http HttpUtils.java
Shouldn't that be amp; instead? -jh- [EMAIL PROTECTED] wrote: jfarcand2002/12/13 08:47:29 Modified:jsr154/src/share/javax/servlet/http HttpUtils.java Log: Doclets bombs when processing this file (minor fix) Submitted by: Ryan Lubke Revision ChangesPath 1.3 +1 -1 jakarta-servletapi-5/jsr154/src/share/javax/servlet/http/HttpUtils.java Index: HttpUtils.java === RCS file: /home/cvs/jakarta-servletapi-5/jsr154/src/share/javax/servlet/http/HttpUtils.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- HttpUtils.java15 Oct 2002 21:39:44 - 1.2 +++ HttpUtils.java13 Dec 2002 16:47:28 - 1.3 @@ -104,7 +104,7 @@ * The query string should be in the form of a string * packaged by the GET or POST method, that is, it * should have key-value pairs in the form ikey=value/i, - * with each pair separated from the next by a character. + * with each pair separated from the next by a apos character. * * pA key can appear more than once in the query string * with different values. However, the key appears only once in -- 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: [VOTE] minimal JSR 154 only distribution
It seems Jon is more interested in a release without jsp then in a release that includes velocity. Too bad. I think that's to Jon's credit. It shows the goal isn't to put Velocity and JSP on even footing, but just to provide what users want, which is often a more secure server without JSP. -jh- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: URI handling in tomcat 3.2.3
Marc, Thanks for still thinking about this. :-) And thanks to Lars for raising the interesting point from 2396 that a / has a reserved purpose in a URI and if you want to use it for a different purpose you should escape it. That makes it sound like your patch is a highly reasonable solution, and perhaps the best we can do until the spec can provide more guidance. -jh- Marc Saegesser wrote: Jason, Lars, all, I've been investigating the normalized URL, encoded special characters, etc. issues with Tomcat 3.2.3 and I think I have a solution that both maintains the required level of security and allows the kind of thing that Lars and Jason are looking for. I've attached a patch that I would appreciate reviewed by committers to make sure I'm not missing something. What I've done is changed the existing RequestUtil.URLDecode() to prevent the decoding of some additional characters. There was already code there to prevent '/' and '\0' and I added the other protected chars '\\', '.' and '%'. I then removed the draconian test to 404 any URL containing these special chars. If a URI contains encoded special characters from this list then these characters *remain encoded* in the resulting URI. For example /fu/ba+r -- /fu/ba r /fu%2fba+r -- /fu%2fba r I've tested this with all the 'bad' URLs that used to expose JSP source or avoid security constraints and everything works fine. Tomcat will still normalize all URIs as soon as they arrive in the container (sorry Jason). To avoid normalizing data passed in the pathinfo you will need to encode the path characters and then have your servlet URL decode the path info. For example, assuming /fubar/* is the prefix mapping, http://server/fubar/http:%2f%2fURLInPathInfo or http://server/fubar/http:%2f/URLInPathInfo will return path info that can be decoded URLDecoder.decode() into http://URLInPathInfo. Comments? Marc Saegesser -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 12:49 PM To: [EMAIL PROTECTED] Subject: RE: URI handling in tomcat 3.2.3 Lars, I agree with you. These encoded characters should be allowed in URIs and disallowing them is a hack. Like I said, I think the approach sucks. We were faced with a very serious security problem that had to be addressed very quickly and the decision was made that it was better to forbid certain 'odd' URIs in order to guarantee that resources that the specification *requires* to be protected were indeed protected. We need to look into how to solve the security problems without forbidden valid URIs, but right now I'm about the only one around paying much attention to the tomcat_32 branch so I don't know what kind of time frame wold be involved to get this changed. I do know that the solution will not be trivial. I mentioned Apache httpd only to show that our approach to this problem is in-line with that taken by other industry leading products. We should not (and I think have not) blindly follow httpd (it does a few other things that disagree with). Patches or discussion on how to go about fixing this are certainly welcome! Marc Saegesser -Original Message- From: Lars Oppermann [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 9:23 AM To: [EMAIL PROTECTED] Subject: Re: URI handling in tomcat 3.2.3 Hi Marc, Thanks for you reply... Marc Saegesser wrote: I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. From what I understand, these security problems are all related to mapping URIs to filesystem paths. So how do you feel about doing this processing in the filesystem (default) servlet? Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. [400 with Apache 1.3.19] I think, if it is possible to do this in a better way while keeping up the protection there is no reason for copying the behaviour of httpd. However, if those security implications can not be handled in the file servlet like I mentioned before, I'd need to do some more thinking on this point. If you need to pass this sort of data to a servlet (or CGI) the most portable way is to simply use a query string. Yes, that sounds like a straight-forward solution. Unfortunatly the service that gets excuted here will access some document and return an html representation. This document contains relative references within the hierarchy represented by the 'wrapped' URI. for this to work with a browser, the request URI has to be used, because the client can not resolve relative references
Re: URI handling in tomcat 3.2.3
You only use http:// in the GET request if you're talking to a proxy server. That's probably why you got the bad request error, not because of the %2f. You should try: GET /cgi-bin/dumpenv.bat/fu%2fbar HTTP/1.1 -jh- Marc Saegesser wrote: Oops, minor correction. Apache actually returns 400 Bad Request Here's the telnet session GET http://localhost:8081/cgi-bin/dumpenv.bat/fu%2fbar HTTP/1.1 server: msaegesserlpt HTTP/1.1 400 Bad Request Date: Thu, 13 Sep 2001 13:51:21 GMT Server: Apache/1.3.19 (Win32) mod_jk Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 18b !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE400 Bad Req uest/TITLE /HEADBODY H1Bad Request/H1 Your browser sent a request that th is server could not understand.P client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /cgi-bin/dumpenv.bat/fu%2fbarP HR ADDRESSApache /1.3.19 Server at msaegesserlpt Port 8081/ADDRESS /BODY/HTML 0 Connection to host lost. Marc Saegesser -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 8:48 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: URI handling in tomcat 3.2.3 I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. In fact we lifted our restriction on encoded special characters straight from Apache HTTPD. In your example URL, if /app/UCB was a CGI script then you would still get a 404 on Apache (at least on Apache 1.3.19 which is what I tested with). If you need to pass this sort of data to a servlet (or CGI) the most portable way is to simply use a query string. Marc Saegesser -Original Message- From: Lars Oppermann [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 5:00 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: URI handling in tomcat 3.2.3 Hi everyone, we were in progress of moving our project to tomcat 3.2.3 when we came accross the new handling of URIs (release-notes sec. 7.2). Since we are using the URI to transport other hierarchical information then filesystem paths, we have the feeling, that this kind of functionality belongs to the default servlet serving filesystem requests. Especialy the fact that %25, %2E, %2F and %5c inside an URI lead to a 404 error seems to somewhat strange. For Example: http://server/app/UCB/vnd.sun.star.hier:%2F/address/myresource would be rejected, before app has teh possibilty to look at the request and ...hier://address/myfile... would be normalized to hier:/address. We are perfectly aware of the security concerns behind these changes. However, they only apply when serving resources from the filesystem. A URL's path-components however are in no way bound to the representaion of filesystem paths.(After all, the U in URL stands for universal :) RFC 2396 states that '/' in an URI has another semantic meaning then %2F in an URI. The '/' seperates path-components, while the %2F means a slash character in a path-component. When such an URI is mapped to a filesystem this would denote a filename that contains a slash. When the system does not allow for such names, it is the responsebilty of the filesystem servlet to report an error (404 since such a file must not exist on unix for example). What are your opinions on this? Cheers -Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop Sachsenfeld 4 Phone: +49 40 23646 959D-20097 Hamburg Fax: +49 40 23646 550 http://www.sun.com/webtop
Re: New resource: Bugs every servlet programmer should know about
Good suggestion, Craig. I've updated the list to include this. I also incorporated all the other comments from the people who wrote me. Glad to see the ajp13 issue is fixed in 3.2.3! -jh- Craig R. McClanahan wrote: Jason, One family of bugs you might want to include pertains to app servers that still use the Jasper engine from Tomcat 3.1 in their current production versions (such as IBM's WebSphere 3.5.3 and earlier). Such servers inherit a large number of bugs from that Jasper code -- one that bites many users is the fact that this Jasper does not let you use pageContext.removeAttribute() to remove an attribute from request scope. Craig On Mon, 10 Sep 2001, Jason Hunter wrote: Date: Mon, 10 Sep 2001 22:11:25 -0700 From: Jason Hunter [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: New resource: Bugs every servlet programmer should know about I just posted on Servlets.com a new resource listing the top bugs a servlet/JSP programmer should know about. They're culled from my email inbox, based on the most frequently reported problems sent to me by users. Several directly involve Apache/Tomcat, so I thought this would be a good forum in which to post a mention. http://www.servlets.com/soapbox/bugs.html If you know of other similarly high profile bugs, please let me know. -jh-
Re: Tomcat 3.2.3 and getPathInfo
I'd still like to see Tomcat allow the slashes. Here's my argument: * Allowing two adjacent slashes to remain is not a security risk * The Apache Web Server allows the slashes to remain * Tomcat used to allow the slashes to remain * Code (like mine) which used to work with Tomcat is now breaking * It's breaking a book example too, which may cause lots of bug reports (to both of us) * Unless the spec says to normalize beyond what's necessary, Tomcat shouldn't normalize beyond what's necessary -jh- Marc Saegesser wrote: After looking into this further I've changed my mind. I've tried this using other web servers (iPlanet, IIS 4.0 and 5.0) and in all cases the value in PATH_INFO has been fully normalized including removing adjacent / characters. IIS gets the contents of PATH_INFO wrong, but it is fully normalized. The CGI 1.1 specification is silent on this topic (like it is on most other important details). I think we should leave Tomcat as it currently is in 3.2.3. If you need to pass data to a servlet in the URL and that data *must not* be susceptible to URL normalization then the data *must* be in the query string. Marc Saegesser -Original Message- From: Jason Hunter [mailto:[EMAIL PROTECTED]] Sent: Monday, August 27, 2001 8:45 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 and getPathInfo Marc Saegesser wrote: Using Apache 1.3.19 here's what I see. Apache does normalize the URL but there is a small difference between what it does and what Tomcat does. Apache does not remove multiple adjacent / characters. For example, http://server/cgi-bin/script/fu/bar -- PATH_INFO = /fu/bar http://server/cgi-bin/script/fu/../bar -- PATH_INFO = /bar http://server/cgi-bin/script/fu//bar -- PATH_INFO = /fu//bar The multiple adjacent / characters don't seem to have any effect on locating resources. For example, http://server///cgi-bin/script/fu/bar works just fine. Unless other comitters feel otherwise, I'll work on changes to the tomcat_32 branch to make path info work as it does with CGI in Apache. Perfect, then my issue (at least) would be solved. -jh-
New resource: Bugs every servlet programmer should know about
I just posted on Servlets.com a new resource listing the top bugs a servlet/JSP programmer should know about. They're culled from my email inbox, based on the most frequently reported problems sent to me by users. Several directly involve Apache/Tomcat, so I thought this would be a good forum in which to post a mention. http://www.servlets.com/soapbox/bugs.html If you know of other similarly high profile bugs, please let me know. -jh-
Re: Tomcat 3.2.3 and getPathInfo
Marc Saegesser wrote: Using Apache 1.3.19 here's what I see. Apache does normalize the URL but there is a small difference between what it does and what Tomcat does. Apache does not remove multiple adjacent / characters. For example, http://server/cgi-bin/script/fu/bar -- PATH_INFO = /fu/bar http://server/cgi-bin/script/fu/../bar -- PATH_INFO = /bar http://server/cgi-bin/script/fu//bar -- PATH_INFO = /fu//bar The multiple adjacent / characters don't seem to have any effect on locating resources. For example, http://server///cgi-bin/script/fu/bar works just fine. Unless other comitters feel otherwise, I'll work on changes to the tomcat_32 branch to make path info work as it does with CGI in Apache. Perfect, then my issue (at least) would be solved. -jh-
Tomcat 3.2.3 and getPathInfo
It seems that Tomcat 3.2.3 has a bug (a regression) that hits my book's Example 5-5. See: http://www.servlets.com/jservlet2/examples/ch05/index.html#ex05_05 The bug is that for the following URL: http://www.servlets.com/jservlet2/examples/ch05/goto/http://www.servlets.com the goto servlet should have extra path info of http://www.servlets.com; and in fact does with Tomcat 3.2.1 but with 3.2.3 it now returns /www.servlets.com. My guess is the server may be trying to do a windows to unix filename conversion? It could also be a side effect of decoding, although there are no special chars there to be decoded. Is this a known issue? I didn't find anything with a quick list scan. -jh-
Re: Tomcat 3.2.3 and getPathInfo
Marc Saegesser wrote: I just tried this using the SnoopServlet that ships with Tomcat using a URL like http://localhost:8080/servlet/SnoopServlet/http://fubar and got /http:/fubar as the path info. Your description makes it look like your losing http: in addition to the one of the /s. Is this what your seeing? Using SnoopServlet I see /http:/fubar just like you. My seeing the http: being eaten was due to how the GoTo servlet responded to the illegal URL being used. So that's good, it's only the double-slash to single-slash issue. It's a hard issue, but a straightforward issue. This problem is almost certainly caused the URL normalization code that got put into 3.2.3 to fix a serious security hole. This is going to be difficult to resolve. We have to normalize the URL before the servlet container uses it (I think this is even going to be added to the latest servlet specification) or some really bad things can happen with prefix mapping. However, until we've done the prefix mapping we can't know what part of the URL refers to a servlet and what part is path info. Getting back the original non-normalized path info is going to be tricky. I don't recall any EG discussion about normalizing the URL before the container sees it. Generally the spec makes contracts on the container as it interfaces with the servlet and doesn't make any statements about a web server might support a plug-in. This is even worse because we also won't allow the URL to be encoded like http://localhost:8080/servlet/SnoopServlet/http:%2F%2Ffubar because we make some rather draconian precautions to ensure that nastily encoded URLs can't obtain access to protected resources (or even resources outside the webapp). Hmm... I wonder if Tomcat has the right to make illegal what HTTP would allow? I'll have to give this one some thought. If URL normalization is being added to the specification then there should also some guidance on how it relates to path info. As I understand it, extra path info has to be returned in its simple decoded form. -jh-
Possible ajp13 bug doing file upload posts
Hi,
Here's a bug report in ajp13 from someone using my com.oreilly.servlet
package to do file uploads. No real details, but I'm thinking perhaps
someone with ajp13 running can test the file upload example? You can
download the c.o.s. pkg from
http://www.servlets.com/resources/com.oreilly.servlet. I'm happy to
provide support.
-jh-
Hi Jason,
the new year startet well. Because we found out why the upload servlet
didn't work.
The upload didn't work with the "ajp13 Worker". With the
"ajp12 Worker" all works fine.
Thanks for your help and a happy new year.
Cheers Bernhard
===
Bernhard Herlemann
Software Developer
Tel.: +49 781 96 92 96 2
Email: [EMAIL PROTECTED]
www.skyon.com
ASOC has become Skyon AG
Central Call0700-SKYON-888
-Ursprngliche Nachricht-
Von: "Jason Hunter" [EMAIL PROTECTED]
An: "Bernhard Herlemann" [EMAIL PROTECTED]
Gesendet: Mittwoch, 13. Dezember 2000 20:49
Betreff: Re: Tomcat 3.2 / upload servlets
It's working for me with Tomcat 3.2.1 on Win2K.
Although I notice upload.war was incorrectly putting the content in an
upload directory. Perhaps that's the problem?
-jh-
Bernhard Herlemann wrote:
Hi,
If I try your original example
--with Tomcat 3.1 everything is ok,
Output:
UploadTest
Params:
submitter = Bernhard
Files:
name: file
filename: aktien.js
type: application/x-javascript
length: 14232
--With Tomcat 3.2 the browser says that the page could not be shown.
No page seams to be generated by the servlet. The servlet engine doesn't
show a any message.
Did you test the example with Tomcat 3.2
Cheers
Bernhard
===
Bernhard Herlemann
Software Developer
Tel.: +49 781 96 92 96 2
Email: [EMAIL PROTECTED]
www.skyon.com
ASOC has become Skyon AG
Central Call0700-SKYON-888
So what happens if you try my exact example?
Your code seemed to call trim() on sTypeOfUpload which must be null, and
I believe null is a reasonable value there.
-jh-
-Ursprngliche Nachricht-----
Von: Bernhard Herlemann
An: Jason Hunter
Gesendet: Dienstag, 12. Dezember 2000 14:43
Betreff: Re: Tomcat 3.2 / upload servlets
Hi,
for testing I wrote a little servlet which is very similar to your example
code.
I added it to this mail.
It also doesn't work with the new tomcat engine.
But unfortunately the new servlet doesn't give an error message on the
console.
I'm not sure if the old error message is usefull.
Here's the code near to the error message.
107File fDirUpload;
108 if(sTypeOfUpload.trim().equals("wap") )
109 fDirUpload = new
ile( "C:\\Apache\\htdocs\\skyon\\sems\\wap_upload" );
Regards
Bernhard
Our configuration:
Servlet-Engine: Tomcat 3.2
Adapter: mod_jk
Windows NT SP 6
Protocoll: ajp12 und ajp13
===
Bernhard Herlemann
Software Developer
Tel.: +49 781 96 92 96 2
Email: [EMAIL PROTECTED]
www.skyon.com
ASOC has become Skyon AG
Central Call 0700-SKYON-888
-Ursprngliche Nachricht-
Von: "Jason Hunter" [EMAIL PROTECTED]
An: "Bernhard Herlemann" [EMAIL PROTECTED]
Gesendet: Montag, 11. Dezember 2000 18:52
Betreff: Re: Tomcat 3.2 / upload servlets
It would help to know what's on line 108 of upload.java.
-jh-
Bernhard Herlemann wrote:
Hi,
I wrote a upload-Servlet using your class
"com.oreilly.servlet.*;"
with Tomcat 3.1 on Win NT and all worked well.
After switching to Tomcat 3.2 I got a NullPointerException.
Maybe you could give a hint.
Cheers
Bernhard Herlemann
java.lang.NullPointerException
at upload.doPost(upload.java:108)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:4
04)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372
)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.
java:797)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743
)
at
org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processCon
nection(Ajp13ConnectionHandler.java:160)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:
416)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java
:498)
at java.lang.Thread.run(Thread.java:484)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
