DO NOT REPLY [Bug 41463] New: - Exception report with IE but not firefox!

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41463

   Summary: Exception report with IE but not firefox!
   Product: Tomcat 6
   Version: 6.0.7
  Platform: PC
OS/Version: Windows Server 2003
Status: NEW
  Severity: critical
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi there, we have a problem running JSPWiki under Tomcat, when using Internet 
Explorer. It's fine in Firefox and doesn't display any exceptions as shown 
below!

This has happened since installing the JCIFS code into web.xml for user 
authentication.
The JSPWiki developers can't help me, they said it sounds more like an 
interplay issue between Tomcat and IE. 


java.io.UnsupportedEncodingException: Cp850
sun.io.Converters.getConverterClass(Unknown Source)
sun.io.Converters.newConverter(Unknown Source)
sun.io.ByteToCharConverter.getConverter(Unknown Source)
java.lang.StringCoding.decode(Unknown Source)
java.lang.String.(Unknown Source)
java.lang.String.(Unknown Source)
jcifs.ntlmssp.Type1Message.parse(Type1Message.java:236)
jcifs.ntlmssp.Type1Message.(Type1Message.java:86)
jcifs.http.NtlmSsp.authenticate(NtlmSsp.java:88)
jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:160)
jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114)

com.ecyrd.jspwiki.ui.WikiServletFilter.doFilter(WikiServletFilter.java:99)
com.ecyrd.jspwiki.ui.WikiJSPFilter.doFilter(WikiJSPFilter.java:71)

Hope to hear from you soon..and well done on such a marvellous product!

Regards

Chris Tamburro
ICT Department
St. Edward's School
Cheltenham, UK

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38489] - Frequent Broken Pipe Error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38489


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38489] - Frequent Broken Pipe Error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38489





--- Additional Comments From [EMAIL PROTECTED]  2007-01-25 08:28 ---
This bug still occurs in Tomcat 5.5.17.  We are able to recreate the bug by
putting the server under heavy load and frequently clicking new links in the
navigation tree of our web application.

It seems as though Tomcat is not correctly handling connections to Apache that
are closed (due to end-user's browser aborting the connection).  It seems that
Tomcat is in the process of writing to the output stream when it is closed.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41466] - NIO Connector: IllegalArgumentException: You can only write using the application write buffer provided by the handler

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41466





--- Additional Comments From [EMAIL PROTECTED]  2007-01-25 09:17 ---
Created an attachment (id=19460)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19460&action=view)
A patch fixing the issue, but not meant to be a definitive patch

Should fix this differently since it removes a useful check that is not valid
in only one special case (sendAck call)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41466] New: - NIO Connector: IllegalArgumentException: You can only write using the application write buffer provided by the handler

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41466

   Summary: NIO Connector: IllegalArgumentException: You can only
write using the application write buffer provided by the
handler
   Product: Tomcat 6
   Version: 6.0.7
  Platform: All
OS/Version: Windows XP
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Trying to use NIO connector instead of APR connector using Tomcat6 HEAD, I get
an IllegalArgumentException while in a call to sendAck.  

Looking at InternalNioOutputBuffer.sendAck(), it uses ByteBuffer.wrap() to
create a new ByteBuffer and uses this ByteBuffer in a call to writeToSocket.
There is a check in SecureNioChannel.write() that the ByteBuffer is the one
stored in the 

Commenting the line 372 in SecureNioChannel.java fixes the problem.
//if ( src != bufHandler.getWriteBuffer() ) throw new
IllegalArgumentException("You can only write using the application write buffer
provided by the handler.");
But I guess that the check is here for a valid reason, and a better fix would
very likely consist in fixing the sendAck or in adding an "or" condition to the
test for the case of sendAck().

GRAVE: Cannot find message associated with key 
standardWrapper.acknowledgeException
java.lang.IllegalArgumentException: You can only write using the application
write buffer provided by the handler.
at 
org.apache.tomcat.util.net.SecureNioChannel.write(SecureNioChannel.java:372)
at 
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:111)
at
org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:434)
at
org.apache.coyote.http11.InternalNioOutputBuffer.sendAck(InternalNioOutputBuffer.java:418)
at 
org.apache.coyote.http11.Http11NioProcessor.action(Http11NioProcessor.java:1028)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.acknowledge(Response.java:310)
at 
org.apache.catalina.connector.Response.sendAcknowledgement(Response.java:1154)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:169)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
at 
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:888)
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:624)
at 
org.apache.tomcat.util.net.NioEndpoint$Worker.run(NioEndpoint.java:1467)
at java.lang.Thread.run(Thread.java:595)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41467] New: - the $ character is being removed from

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41467

   Summary: the $ character is being removed from

   Product: Tomcat 5
   Version: 5.0.28
  Platform: All
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P1
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I ran into an interesting bug.  The password for my database was recently 
changed and the password contains the '$' character.  When I updated server.xml 
and started Tomcat I got invalid username/password errors.  I dug into the 
problem a little deeper and found that if I set the password value to 
be "abc$123" then when the value got down to the Oracle driver it would 
be "abc123" with the $ character removed.  

   
  
password
abc$123
  


Digging deeper I found the source of the problem to be the 
org.apache.tomcat.util.IntrospectionUtils class, specifically the method:

public static String replaceProperties(String value, Hashtable staticProp, 
PropertySource dynamicProp[] ) { ...  }

I guessing that if this method does not find something of the pattern ${...} 
then it tries to put the string back together again but it's not putting it 
back together again properly because I loose my '$'.  Plus I don't see anything 
in the code which would allow me to escape the processing.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41463] - Exception report with IE but not firefox!

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41463





--- Additional Comments From [EMAIL PROTECTED]  2007-01-25 10:08 ---
Created an attachment (id=19461)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19461&action=view)
web.xml for this problem!!


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible javax.servlet.http.HttpServlet bugs, and where to report them?

[Jan Luehe]

Hi Mike,

> I think there's a bug in javax.servlet.http.HttpServlet, but I'm not 
sure where to report it.
> I'm posting this here for the time being (and possibly on the 
Glassfish "issue tracker" if and
> when I can jump through the hoops required to do so), but please let 
me know if it ought to be

> reported some other way: and apologies if this doesn't belong here!

I found another problem with HttpServlet's NoBodyOutputStream: If you use
getWriter(), the returned writer is constructed as follows:

   OutputStreamWriter w = new OutputStreamWriter(
   noBody, getCharacterEncoding());
   writer = new PrintWriter(w);

Notice that when you wrap an OutputStreamWriter around noBody, the
output will be buffered by the OutputStreamWriter before it is written
to "noBody", meaning that when NoBodyOutputStream.setContentLength()
is called, noBody.getContentLength() will return 0 if the output is still
buffered. Therefore, NoBodyOutputStream.setContentLength() needs to
flush the writer (if one is being used) before calling 
noBody.getContentLength(),

as follows:

   void setContentLength() {
   if (!didSetContentLength) {
   // BEGIN PATCH
   if (writer != null) {
   writer.flush();
   }
   // END PATCH
   setContentLength(noBody.getContentLength());
   }
   }

Let me know what you think.

Thanks,


Jan




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36365] - IIS5.1-isapi_redirector.dll (1.2.14) plugin issue

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36365


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
   ||com




--- Additional Comments From [EMAIL PROTECTED]  2007-01-25 15:14 ---
Can we get this issue patched - I've suddenly got a cluster of products that
have decided to use HTTP PUTs through IIS, and this is breaking the development
environments.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible javax.servlet.http.HttpServlet bugs, and where to report them?

[Mark Thomas]

Jan Luehe wrote:
> please go to https://servlet-spec-eg.dev.java.net/
> and request observer role.

I tried by I can't access any of the project. My id is medthomas.
Could you forward the request for me?

Many thanks,

Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible javax.servlet.http.HttpServlet bugs, and where to report them?

[Jan Luehe]

Hi Mark,

Mark Thomas wrote On 01/25/07 04:33 PM,:


 Jan Luehe wrote:

> please go to https://servlet-spec-eg.dev.java.net/ and request
> observer role.


 I tried by I can't access any of the project. My id is medthomas.
 Could you forward the request for me?


I'm forwarding the message I just sent to the EG, which has
the proposed diffs.

Thanks,

Jan




 Many thanks,

 Mark


--- Begin Message ---

Based on feedback from Mike Kaufman (see
https://servlet-spec-eg.dev.java.net/issues/show_bug.cgi?id=40),
and a bug I discovered, I propose that we make the following
backwards-compatible changes to javax.servlet.http.HttpServlet.

I've attached the diffs, and also copied the relevant parts of the
code that are going to change, where the diffs are hard to read.

Summary of changes:

- Have NoBodyResponse extend HttpServletResponseWrapper, which will
 avoid a lot of redundant implementation code for this class.
 With this change, NoBodyResponse will continue to implement
 HttpServletResponse.

 Make sure that calling getOutputStream() after getWriter() (or vice
 versa) results in an IllegalStateException, as required by the servlet
 spec.

 Also make sure that if getWriter() has been called, the writer is
 flushed before the getContentLength() method of the writer's underlying
 NoBodyOutputStream is called (otherwise, the resulting Content-Length
 will always be equal to zero).

 Here are the relevant code changes for NoBodyResponse:

 CHANGE:

   class NoBodyResponse implements HttpServletResponse {

 TO:

   class NoBodyResponse extends HttpServletResponseWrapper {

 
 CHANGE:

   NoBodyResponse(HttpServletResponse r) {
   resp = r;
   noBody = new NoBodyOutputStream();
   }

 TO

   NoBodyResponse(HttpServletResponse r) {
   super(r);
   noBody = new NoBodyOutputStream();
   }

 
 CHANGE:

   void setContentLength() {
   if (!didSetContentLength)
 resp.setContentLength(noBody.getContentLength());
   }

 TO:

   void setContentLength() {
   if (!didSetContentLength) {
   if (writer != null) {
   writer.flush();
   }
   setContentLength(noBody.getContentLength());
   }
   }

 
 CHANGE:

   public ServletOutputStream getOutputStream() throws IOException
 { return noBody; }

 TO:

   public ServletOutputStream getOutputStream() throws IOException {

   if (writer != null) {
   throw new IllegalArgumentException(
   lStrings.getString("err.ise.getOutputStream"));
   }
   usingOutputStream = true;

   return noBody;
   }

 
 CHANGE:

   public PrintWriter getWriter() throws UnsupportedEncodingException
   {
   if (writer == null) {
   OutputStreamWriter  w;

   w = new OutputStreamWriter(noBody, getCharacterEncoding());
   writer = new PrintWriter(w);
   }
   return writer;
   }

 TO:

   public PrintWriter getWriter() throws UnsupportedEncodingException {

   if (usingOutputStream) {
   throw new IllegalArgumentException(
   lStrings.getString("err.ise.getWriter"));
   }

   if (writer == null) {
   OutputStreamWriter w = new OutputStreamWriter(
   noBody, getCharacterEncoding());
   writer = new PrintWriter(w);
   }

   return writer;
   }

- Added comment explaining why NoBodyOutputStream.write() really should
 have thrown an IllegalArgumentException (instead of IOException) on
 negative lengths to begin with, and why changing this would break
 backwards compatibility.

- Have NoBodyOutputStream.write() throw the localized error message
 corresponding to the "err.io.negativelength" error code.

- Removed the "close();" and "return;" statements from HttpServlet.doTrace()


Please let me know if you have any concerns about these changes.

Thanks,


Jan

ld.so.1: /usr/bin/sparcv9/uptime: warning: libsocks5_sh.so: open failed: No 
such file in secure directories
Index: HttpServlet.java
===
RCS file: 
/cvs/glassfish/servlet-api/src/jakarta-servletapi-5/jsr154/src/share/javax/servlet/http/HttpServlet.java,v
retrieving revision 1.3
diff -u -r1.3 HttpServlet.java
--- HttpServlet.java14 Mar 2006 21:28:49 -  1.3
+++ HttpServlet.java26 Jan 2007 00:49:46 -
@@ -279,7 +279,7 @@
NoBodyResponse response = new NoBodyResponse(resp);

doGet(req, response);
-   response.setContentLength();
+response.setContentLength();
 }
 
 
@@ -654,8 +654,6 @@
resp.setContentLength(responseLength);
ServletOutputStream out = resp.getOutputStream();
out.print(responseString);  
-   out.close();
-   return;
 }