soTimeout not worked on channelNioSocket

[William Leung]

I have configuared tomcat to use the NIO impl over AJP, here are the lines in
server.xml 
 

(TC version 5.5.17) 
I had setted the soTimeout with 10 minutes, cause I notice such stages in
server status 

Stage Time B Sent B Recv Client VHost Request 
S 33280840 ms 359 KB 0 KB x.x.x.x 127.0.0.1 GET ... 

That shows several requests were blocking on reading request bodies for
hours. 

But unfortunately it dosen't worked for me, I am expecting a request should
only blocking mostly 10 minutes on read, after that a SocketTimeoutException
should raised. 

After digest the source code of ChannelNioSocket.java, I found that
ChannelNioSocket.SocketInputStream just wait infinitly if no data comes
while socket could not be detected closing 

private void block(int len) throws IOException { 
... ... 
if(!dataAvailable) { 
blocking = true; 
if(log.isDebugEnabled()) 
log.debug("Waiting for "+len+" bytes to be available"); 
try{ 
wait(socketTimeout); 
}catch(InterruptedException iex) { 
log.debug("Interrupted",iex); 
} 
blocking = false; 
} 
if(dataAvailable) { 
dataAvailable = false; 
if(fill(len) < 0) { 
isClosed = true; 
} 
} 
} 

The socketTimeout parameter is not used to throw SocketTimeoutException,
actually it has no meaning. 

I even read the source for TC 6.0.13, the same as above. 

Should it be more precisely that throwing SocketTimeoutException on later
condiction test for (dataAvailable) is not true? 

In ChannelSocket implement, the problem is not exists,  it uses blocking
Socket.getInputStream, and it would throws SocketTimeoutException for socket
timeout while Socket.setSoTimeout was called

-- 
View this message in context: 
http://www.nabble.com/soTimeout-not-worked-on-channelNioSocket-tf4586319.html#a13091614
Sent from the Tomcat - Dev mailing list archive at Nabble.com.


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

DO NOT REPLY [Bug 43569] New: - Tomcat instances exceed 70 on startup

[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=43569

   Summary: Tomcat instances exceed 70 on startup
   Product: Tomcat 5
   Version: 5.0.28
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: critical
  Priority: P2
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Morning,

I have an unusual problem with my previously stable container which now
generates over 70 instance on startup. This container has been working correctly
of over 12 months, and I am assured by our dev team that no discrete
modifications have been made. On startup this output is generated: -

start_apps MerchantAdmin
Starting MerchantAdmin
Using CATALINA_BASE:   /rel/apps/MerchantAdmin
Using CATALINA_HOME:   /rel/tomcat
Using CATALINA_TMPDIR: /rel/apps/MerchantAdmin/temp
Using JAVA_HOME:   /usr/lib/java
/rel/tomcat/bin/start_apps.sh: line 36: 30725
30727
30728
30729
30730
30731
30732
30733
30734
30735
30736: syntax error in expression (error token is "30727
30728
30729
30730
30731
30732
30733
30734
30735
30736")

After a min or so, the following number of instances are running: -

> ps aux | grep -c MerchantAdmin
71

I would appreciate any guidance with this issue.

Regards

Ray

-- 
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]

Embedded Tomcat Auto Deploy War

[Christopher Johnson]

All -

I've managed to created a embedded tomcat working based off various
examples I've found online and can successfully add the desired
context to my server, although when the context is packaged as a war
file I my embedded tomcat wont auto deploy it,  how to do construct an
embedded tomcat to auto deploy war files?  If someone could point me
towards an example that would be great.

Thanks in advance,
..Chris

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

DO NOT REPLY [Bug 43569] - Tomcat instances exceed 70 on startup

[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=43569


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-10-08 04:16 ---
Please use the tomcat user list to debug this. Bugzilla is a not a support 
forum.

http://tomcat.apache.org/faq/unix.html#ps

-- 
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: svn commit: r582597 - /tomcat/tc6.0.x/trunk/STATUS

[Filip Hanik - Dev Lists]

I did, but folks shouldn't have to dig through the dev archives, should 
they :)


Filip

Peter Rossbach wrote:

Hi Filip,

has you seen my "Call stopAwait at StandardServer.stop" mail?

Peter


Am 07.10.2007 um 17:10 schrieb Filip Hanik - Dev Lists:

don't forget to include a link to the diff file, so that it can be 
reviewed before committed, just in case someone misses the dev email


Filip

[EMAIL PROTECTED] wrote:

Author: pero
Date: Sun Oct  7 01:36:51 2007
New Revision: 582597

URL: http://svn.apache.org/viewvc?rev=582597&view=rev
Log:
add change request: call StandardServer stopAwait

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=582597&r1=582596&r2=582597&view=diff 

== 


--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Sun Oct  7 01:36:51 2007
@@ -44,4 +44,7 @@
   update to 
jdt.loc=http://sunsite.informatik.rwth-aachen.de/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip 


   +1: pero
   -1: -  \ No newline at end of file
+
+* Call StopAwait at StandardServer.stop as port==-1
+  +1: pero
+  -1:


-
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: soTimeout not worked on channelNioSocket

[Filip Hanik - Dev Lists]

I haven't seen any work done on the NIO part of AJP in a very long time, 
so what I would suggest you do is


1. submit a bug report at 
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%206

2. If possible, provide a patch

Filip

William Leung wrote:

I have configuared tomcat to use the NIO impl over AJP, here are the lines in
server.xml 

   channelNioSocket.port="8009" 
   channelNioSocket.soTimeout="60" 
   channelNioSocket.bufferSize="16384" 
   channelNioSocket.maxThreads="125" 
   channelNioSocket.minSpareThreads="10" 
   channelNioSocket.maxSpareThreads="50" 

   redirectPort="8443" protocol="AJP/1.3" 
   useBodyEncodingForURI="true" 
   /> 

(TC version 5.5.17) 
I had setted the soTimeout with 10 minutes, cause I notice such stages in
server status 

Stage Time B Sent B Recv Client VHost Request 
S 33280840 ms 359 KB 0 KB x.x.x.x 127.0.0.1 GET ... 


That shows several requests were blocking on reading request bodies for
hours. 


But unfortunately it dosen't worked for me, I am expecting a request should
only blocking mostly 10 minutes on read, after that a SocketTimeoutException
should raised. 


After digest the source code of ChannelNioSocket.java, I found that
ChannelNioSocket.SocketInputStream just wait infinitly if no data comes
while socket could not be detected closing 

private void block(int len) throws IOException { 
... ... 
if(!dataAvailable) { 
blocking = true; 
if(log.isDebugEnabled()) 
log.debug("Waiting for "+len+" bytes to be available"); 
try{ 
wait(socketTimeout); 
}catch(InterruptedException iex) { 
log.debug("Interrupted",iex); 
} 
blocking = false; 
} 
if(dataAvailable) { 
dataAvailable = false; 
if(fill(len) < 0) { 
isClosed = true; 
} 
} 
} 


The socketTimeout parameter is not used to throw SocketTimeoutException,
actually it has no meaning. 

I even read the source for TC 6.0.13, the same as above. 


Should it be more precisely that throwing SocketTimeoutException on later
condiction test for (dataAvailable) is not true? 


In ChannelSocket implement, the problem is not exists,  it uses blocking
Socket.getInputStream, and it would throws SocketTimeoutException for socket
timeout while Socket.setSoTimeout was called

  



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

Re: svn commit: r582597 - /tomcat/tc6.0.x/trunk/STATUS

[Peter Rossbach]

OK!

How we can easier promote and discuss those patches? You are right,  
an email threads are not easy to reference at STATUS file. Arrg!
I  don't think that the apache developer home folder are the right  
place for those patches!


Open a bug report for every possible change is also not a good  
solution. But other people can

add there comments and ideas.

Every hint to a standard procedure?

Peter

PS: Can we move the tomcat 5.5 STATUS file to the build project? Then  
it was easier for me to change the file at my eclipse.



Am 08.10.2007 um 17:13 schrieb Filip Hanik - Dev Lists:

I did, but folks shouldn't have to dig through the dev archives,  
should they :)


Filip

Peter Rossbach wrote:

Hi Filip,

has you seen my "Call stopAwait at StandardServer.stop" mail?

Peter


Am 07.10.2007 um 17:10 schrieb Filip Hanik - Dev Lists:

don't forget to include a link to the diff file, so that it can  
be reviewed before committed, just in case someone misses the dev  
email


Filip

[EMAIL PROTECTED] wrote:

Author: pero
Date: Sun Oct  7 01:36:51 2007
New Revision: 582597

URL: http://svn.apache.org/viewvc?rev=582597&view=rev
Log:
add change request: call StandardServer stopAwait

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS? 
rev=582597&r1=582596&r2=582597&view=diff
=== 
===

--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Sun Oct  7 01:36:51 2007
@@ -44,4 +44,7 @@
   update to jdt.loc=http://sunsite.informatik.rwth-aachen.de/ 
eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip

   +1: pero
   -1: -  \ No newline at end of file
+
+* Call StopAwait at StandardServer.stop as port==-1
+  +1: pero
+  -1:


--- 
--

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: svn commit: r582597 - /tomcat/tc6.0.x/trunk/STATUS

[Mark Thomas]

Peter Rossbach wrote:
> OK!
> 
> How we can easier promote and discuss those patches? You are right, an
> email threads are not easy to reference at STATUS file. Arrg!
> I  don't think that the apache developer home folder are the right place
> for those patches!

It will do for now. Once we have trunk (see my latest post on svn
re-org) we can just refer to subversion revision numbers from trunk.

> PS: Can we move the tomcat 5.5 STATUS file to the build project? Then it
> was easier for me to change the file at my eclipse.

Fine with me.

Mark


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

Re: svn commit: r582597 - /tomcat/tc6.0.x/trunk/STATUS

[Filip Hanik - Dev Lists]

since the STATUS file is also a voting forum, there must be a reference 
to an absolute patch/diff. otherwise, the implementation can change 
during the voting phase.

so what I suggest you do is

1. create a .patch file, with your proposed solution
2. upload it to your /home/pero/public_html/patches/ directory
3. put the URL reference to the .patch file in the STATUS file

this seems to work pretty well, and that is what we've been doing
the other option, is to open a BZ item, attach your patch in there

Filip

Peter Rossbach wrote:

OK!

How we can easier promote and discuss those patches? You are right, an 
email threads are not easy to reference at STATUS file. Arrg!
I  don't think that the apache developer home folder are the right 
place for those patches!


Open a bug report for every possible change is also not a good 
solution. But other people can

add there comments and ideas.

Every hint to a standard procedure?

Peter

PS: Can we move the tomcat 5.5 STATUS file to the build project? Then 
it was easier for me to change the file at my eclipse.



Am 08.10.2007 um 17:13 schrieb Filip Hanik - Dev Lists:

I did, but folks shouldn't have to dig through the dev archives, 
should they :)


Filip

Peter Rossbach wrote:

Hi Filip,

has you seen my "Call stopAwait at StandardServer.stop" mail?

Peter


Am 07.10.2007 um 17:10 schrieb Filip Hanik - Dev Lists:

don't forget to include a link to the diff file, so that it can be 
reviewed before committed, just in case someone misses the dev email


Filip

[EMAIL PROTECTED] wrote:

Author: pero
Date: Sun Oct  7 01:36:51 2007
New Revision: 582597

URL: http://svn.apache.org/viewvc?rev=582597&view=rev
Log:
add change request: call StandardServer stopAwait

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=582597&r1=582596&r2=582597&view=diff 

== 


--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Sun Oct  7 01:36:51 2007
@@ -44,4 +44,7 @@
   update to 
jdt.loc=http://sunsite.informatik.rwth-aachen.de/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip 


   +1: pero
   -1: -  \ No newline at end of file
+
+* Call StopAwait at StandardServer.stop as port==-1
+  +1: pero
+  -1:


-
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]







No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.14.4/1056 - Release Date: 10/7/2007 6:12 PM
  



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

DO NOT REPLY [Bug 43572] New: - http POST is refused by Tomcat through mod_jk

[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=43572

   Summary: http POST is refused by Tomcat through mod_jk
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Other
OS/Version: Windows Server 2003
Status: NEW
  Severity: major
  Priority: P2
 Component: Connector:AJP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


A (for me) completely normal http POST is refused by Tomcat (returns 503) when
served through mod_jk. The request works fine when served directly (through
Catalina).

It seems that mod_jk receives the request, and that Tomcat thinks it is a bad
request (responds with 400). Then a retry is initiated, but the second time
Tomcat just refuses with 503.

Here is the request:

-
POST /servlet/FlushServer HTTP/1.1
Connection: close
HOST_SERVICE: FutureTenseContentServer:6.3.0
User-Agent: Jakarta Commons-HttpClient/3.0-rc3
Host: content-test2.website.no:7500
Content-Length: 6450
Content-Type: multipart/form-data; boundary=n9NyrUUS0FIvX9Fqn-iBCN6bhqfLRHoVM

--n9NyrUUS0FIvX9Fqn-iBCN6bhqfLRHoVM
Content-Disposition: form-data; name="password"
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

(topsecret)
--n9NyrUUS0FIvX9Fqn-iBCN6bhqfLRHoVM
Content-Disposition: form-data; name="tags"
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit




















--n9NyrUUS0FIvX9Fqn-iBCN6bhqfLRHoVM
Content-Disposition: form-data; name="username"
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

admin
--n9NyrUUS0FIvX9Fqn-iBCN6bhqfLRHoVM--

-

Here is the log output from my mod_jk log:

[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_uri_worker_map.c (597):
Attempting to map URI '/servlet/FlushServer' from 1 maps
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_uri_worker_map.c (609):
Attempting to map context URI '/servlet/*=ajp13' source 'JkMount'
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_uri_worker_map.c (624):
Found a wildchar match '/servlet/*=ajp13'
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] mod_jk.c (2131): Into handler
jakarta-servlet worker=ajp13 r->proxyreq=0
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_worker.c (115): found a
worker ajp13
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_worker.c (292): Found
worker type 'ajp13'
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] mod_jk.c (811): Service
protocol=HTTP/1.1 method=POST host=(null) addr=158.36.112.211
name=esak-webtest.website.no port=80 auth=(null) user=(null) laddr=158.36.125.14
raddr=158.36.112.211 uri=/servlet/FlushServer
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (2498):
acquired connection pool slot=0
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (551): ajp
marshaling done
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (1935):
processing ajp13 with 2 retries
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (911): sending
to ajp13 pos=4 len=293 max=8192
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (911):   
 12 34 01 21 02 04 00 08 48 54 54 50 2F 31 2E 31  - .4.!HTTP/1.1
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (911): 0010  
 00 00 14 2F 73 65 72 76 6C 65 74 2F 46 6C 75 73  - .../servlet/Flus
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (911): 0020  
 68 53 65 72 76 65 72 00 00 0E 31 35 38 2E 33 36  - hServer...158.36
(.)
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (911): 0110  
 5A 78 41 6B 65 64 6D 37 2D 44 58 69 42 4A 70 75  - ZxAkedm7-DXiBJpu
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (911): 0120  
 35 76 6C 00 FF 00 00 00 00 00 00 00 00 00 00 00  - 5vl.
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (1325):
(ajp13) request body to send 1690 - request body to resend 0
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (911): sending
to ajp13 pos=4 len=1696 max=8192
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (911):   
 12 34 06 9C 06 9A 2D 2D 4B 46 77 34 49 32 51 65  - .4--KFw4I2Qe
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (911): 0010  
 71 36 70 5A 78 41 6B 65 64 6D 37 2D 44 58 69 42  - q6pZxAkedm7-DXiB
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (911): 0020  
 4A 70 75 35 76 6C 0D 0A 43 6F 6E 74 65 6E 74 2D  - Jpu5vl..Content-
[Mon Oct 08 14:00:07.156 2007] [632:5336] [debug] jk_ajp_common.c (911): 0030  
 44 69 73 70 6F 73 69 74 69 6F 6E 3A 20 66 6F 72  - Disposition:.for
(.)
[Mon Oct 08 14:00:07.156 2007] [632:5336] 

DO NOT REPLY [Bug 43209] - HTTP Headers are corrupted with basic authentication

[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=43209





--- Additional Comments From [EMAIL PROTECTED]  2007-10-08 10:17 ---
This appears to be a problem with the Modify Headers extension:
https://www.mozdev.org/bugs/show_bug.cgi?id=17504

I've replicated this with tc6.0.x and ethereal appears to confirm the issue as
client-side:
No. TimeSourceDestination   Protocol Info
  8 18.350781   ::1   ::1   HTTP GET
/testHTTPHeadersCorruptedWithBasicAuthentication-BZ-43209-JIRA-14147/test 
HTTP/1.1

Frame 8 (567 bytes on wire, 567 bytes captured)
Null/Loopback
Internet Protocol Version 6
Transmission Control Protocol, Src Port: 52540 (52540), Dst Port: http-alt
(8080), Seq: 1, Ack: 1, Len: 491
Hypertext Transfer Protocol
GET
/testHTTPHeadersCorruptedWithBasicAuthentication-BZ-43209-JIRA-14147/test
HTTP/1.1\r\n
Host: localhost:8080\r\n
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7)
Gecko/20070914 Firefox/2.0.0.7\r\n
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
xyz: john\r\n
\r\n

No. TimeSourceDestination   Protocol Info
 10 18.352724   ::1   ::1   HTTP
HTTP/1.1 401 Unauthorized (text/html)

Frame 10 (1340 bytes on wire, 1340 bytes captured)
Null/Loopback
Internet Protocol Version 6
Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: 52540
(52540), Seq: 1, Ack: 492, Len: 1264
Hypertext Transfer Protocol
HTTP/1.1 401 Unauthorized\r\n
Server: Apache-Coyote/1.1\r\n
Pragma: No-cache\r\n
Cache-Control: no-cache\r\n
Expires: Wed, 31 Dec 1969 16:00:00 PST\r\n
WWW-Authenticate: Basic realm="Example Basic Authentication"\r\n
Content-Type: text/html;charset=utf-8\r\n
Content-Length: 966\r\n
Date: Mon, 08 Oct 2007 17:02:28 GMT\r\n
\r\n
Line-based text data: text/html

No. TimeSourceDestination   Protocol Info
 12 23.013460   ::1   ::1   HTTP GET
/testHTTPHeadersCorruptedWithBasicAuthentication-BZ-43209-JIRA-14147/test 
HTTP/1.1

Frame 12 (608 bytes on wire, 608 bytes captured)
Null/Loopback
Internet Protocol Version 6
Transmission Control Protocol, Src Port: 52540 (52540), Dst Port: http-alt
(8080), Seq: 492, Ack: 1265, Len: 532
Hypertext Transfer Protocol
GET
/testHTTPHeadersCorruptedWithBasicAuthentication-BZ-43209-JIRA-14147/test
HTTP/1.1\r\n
Host: localhost:8080\r\n
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7)
Gecko/20070914 Firefox/2.0.0.7\r\n
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
xyz: john, john\r\n
Authorization: Basic dXNlcjpwYXNz\r\n
Credentials: user:pass
\r\n

No. TimeSourceDestination   Protocol Info
 14 23.014178   ::1   ::1   HTTP
HTTP/1.1 200 OK

Frame 14 (278 bytes on wire, 278 bytes captured)
Null/Loopback
Internet Protocol Version 6
Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: 52540
(52540), Seq: 1265, Ack: 1024, Len: 202
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Server: Apache-Coyote/1.1\r\n
Pragma: No-cache\r\n
Cache-Control: no-cache\r\n
Expires: Wed, 31 Dec 1969 16:00:00 PST\r\n
Content-Length: 16\r\n
Date: Mon, 08 Oct 2007 17:02:33 GMT\r\n
\r\n
Data (16 bytes)

  78 79 7a 3d 6a 6f 68 6e 2c 20 6a 6f 68 6e 0d 0a   xyz=john, john..

-- 
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: svn commit: r582597 - /tomcat/tc6.0.x/trunk/STATUS

[Tim Funk]

I would think a link is a must. So step 2 can be any of
2a) Upload a patch to /home/`whoami`/public_html/patches
2b) Add a patch to BZ
2c) Link to SVN patch
2d) If the patch is an attachment in an email to tomcat-dev - there is 
some public record of the email - link to that



-Tim

Filip Hanik - Dev Lists wrote:
since the STATUS file is also a voting forum, there must be a reference 
to an absolute patch/diff. otherwise, the implementation can change 
during the voting phase.

so what I suggest you do is

1. create a .patch file, with your proposed solution
2. upload it to your /home/pero/public_html/patches/ directory
3. put the URL reference to the .patch file in the STATUS file



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

DO NOT REPLY [Bug 43209] - HTTP Headers are corrupted with basic authentication

[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=43209


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-10-08 10:39 ---
Marking as invalid since the trace shows a client side issue, rather than a
Tomcat one.

Thanks for the ethereal trace.

-- 
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]

svn commit: r582924 - /tomcat/tc6.0.x/trunk/STATUS

[funkman]

Author: funkman
Date: Mon Oct  8 11:18:14 2007
New Revision: 582924

URL: http://svn.apache.org/viewvc?rev=582924&view=rev
Log:
+1 proposals

abstained from "Call StopAwait at StandardServer.stop as port==-1" since it was 
missing the patch in the status file


Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=582924&r1=582923&r2=582924&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Mon Oct  8 11:18:14 2007
@@ -27,22 +27,22 @@
 
 * Fix explicit flush before response commit in the org.apache.jk AJP connector.
   http://svn.apache.org/viewvc?view=rev&revision=580815
-  +1: remm, pero
+  +1: remm, pero, funkman
   -1: 
 
 * 43479: Memory leak cleaning up sendfile connections (submitted by the bug 
reporter)
   http://issues.apache.org/bugzilla/attachment.cgi?id=20883
-  +1: remm, pero
+  +1: remm, pero, funkman
   -1: 
 
 * 42925: No timeout for sendfile
   http://issues.apache.org/bugzilla/attachment.cgi?id=20930
-  +1: remm, pero
+  +1: remm, pero, funkman
   -1: 
 
 * Use newer eclipse jdt - old location is gone (reported by Jason Britian via 
email)
   update to 
jdt.loc=http://sunsite.informatik.rwth-aachen.de/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
-  +1: pero
+  +1: pero, funkman
   -1: 
 
 * Call StopAwait at StandardServer.stop as port==-1



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

Re: svn commit: r582597 - /tomcat/tc6.0.x/trunk/STATUS

[Filip Hanik - Dev Lists]

I would agree with all these options, basically, the goal is to have a 
reference to an actual patch, otherwise we are voting on someones idea 
of a fix :)


Filip

Tim Funk wrote:

I would think a link is a must. So step 2 can be any of
2a) Upload a patch to /home/`whoami`/public_html/patches
2b) Add a patch to BZ
2c) Link to SVN patch
2d) If the patch is an attachment in an email to tomcat-dev - there is 
some public record of the email - link to that



-Tim

Filip Hanik - Dev Lists wrote:
since the STATUS file is also a voting forum, there must be a 
reference to an absolute patch/diff. otherwise, the implementation 
can change during the voting phase.

so what I suggest you do is

1. create a .patch file, with your proposed solution
2. upload it to your /home/pero/public_html/patches/ directory
3. put the URL reference to the .patch file in the STATUS file



-
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: Commit policy for native Tomcat connectors

[Jim Jagielski]

It doesn't seem like these suffered from the same
issues than core TC did though, so either way is cool.

On Oct 7, 2007, at 4:41 AM, Peter Rossbach wrote:


Hi Rainer,

I think we need a clear policy for all tomcat parts. Currently this  
means that we

must also change the commit policy for jk and tcnative.

Peter


Am 01.10.2007 um 15:46 schrieb Rainer Jung:


Hi,

since the main project agreed on trying a new policy for commits  
against stable branches, I think we should clarify our policy  
concerning the native parts of Tomcat connectors (JK and tcnative).


Both have only one active branch, which at the moment is the  
stable branch as well as the development branch.


The primary purpose of the commit policy is helping to interact  
the comitters in a way, that provides a good balance between  
innovation and stability. The group of committers for the two  
native projects has a different structure than the main Tomcat  
project.


I think that until now we didn't have any incidents that indicate,  
that we should switch to a new policy for the native projects.  
It's possible, that this will be necessary, once development for  
JK3 really starts, in order to concentrate our efforts on the new  
branch.


I would like to gather opinions from the group concerning the  
momentary situation:


- do you also think we can stick to CTR for

   - JK native?

   - tcnative?

I don't expect a lot of change for JK 1.2 (new features) and I  
think we'll switch over to JK3 for all major new features. But  
since we didn't have a problem with CTR on JK 1.2, I would prefer  
sticking to that (for simplicity).


Regards,

Rainer

-
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: svn commit: r582597 - /tomcat/tc6.0.x/trunk/STATUS

[Jim Jagielski]

On Oct 8, 2007, at 12:21 PM, Mark Thomas wrote:


Peter Rossbach wrote:

OK!

How we can easier promote and discuss those patches? You are  
right, an

email threads are not easy to reference at STATUS file. Arrg!
I  don't think that the apache developer home folder are the right  
place

for those patches!


It will do for now. Once we have trunk (see my latest post on svn
re-org) we can just refer to subversion revision numbers from trunk.



+1

(until then, mail-archives URLs work if the patch
was posted on the list)


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

svn commit: r582975 - /tomcat/tc6.0.x/trunk/STATUS

[remm]

Author: remm
Date: Mon Oct  8 14:09:22 2007
New Revision: 582975

URL: http://svn.apache.org/viewvc?rev=582975&view=rev
Log:
- Vote.

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=582975&r1=582974&r2=582975&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Mon Oct  8 14:09:22 2007
@@ -42,7 +42,7 @@
 
 * Use newer eclipse jdt - old location is gone (reported by Jason Britian via 
email)
   update to 
jdt.loc=http://sunsite.informatik.rwth-aachen.de/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
-  +1: pero, funkman
+  +1: pero, funkman, remm
   -1: 
 
 * Call StopAwait at StandardServer.stop as port==-1



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

DO NOT REPLY [Bug 42579] - [Patch] JNDIRealm fails to parse absolute names

[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=42579


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|JNDIRealm fails to parse|[Patch] JNDIRealm fails to
   |absolute names  |parse absolute names




-- 
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 43572] - http POST is refused by Tomcat through mod_jk

[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=43572





--- Additional Comments From [EMAIL PROTECTED]  2007-10-08 16:43 ---
Hi,

thanks for the debug log. Unfortunately, a lot of request forwarding lines are
missing. Did you check, if the full request got forwarded? The lines posted look
like the request got truncated before its end.

Then: the request says it's body is 6450 Bytes but the request you pasted in
here is smaller. If this holds true, then yes: it's a bad request.

If the is no confidential data in the request, could you increase log level to
trace and attach a full log? In case of small confidential parts, you can cross
them out (but don't forget to cross the ascii part and the hex part.

Regards,

Rainer


-- 
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]