Re: [PATCH] - rat-output.xml tweaks for tc8.0.x tc8.5.x trunk

[Huxing Zhang]

Hi Gavin,

Please file the patch to trunk, and it will be backported to 8.5.x, 8.x if 
possible.

--
From:Gavin McDonald 
Time:2016 Sep 23 (Fri) 07:17
To:Tomcat Developers List 
Subject:RE: [PATCH] - rat-output.xml tweaks for tc8.0.x tc8.5.x trunk




> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, September 23, 2016 3:25 AM
> To: Tomcat Developers List 
> Subject: Re: [PATCH] - rat-output.xml tweaks for tc8.0.x tc8.5.x trunk
> 
> Gavin,
> 
> On 9/22/16 1:03 AM, Gavin McDonald wrote:
> > Please find attached 3 patches for tweaks to the rat-excludes file in
> > trunk and the 8.0 and 8.5 branches.
> >
> > RAT tests are currently producing invalid xml reports due to files
> > that should be excluded (and therefore xml parser cant convert to html
> > for pretty reports etc)
> >
> > HTH
> >
> > Gav...
> 
> The attachment(s) must have been stripped. 

Yeah I noticed :(

> Would you like to file a BZ issue
> and attach to that?

Sure, not sure what component to put it under. Ideas ?

The patches affect versions 8, 8.5 and trunk , which version do you want me to 
use?

Thanks

Gav...

> 
> -chris



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

RE: [PATCH] - rat-output.xml tweaks for tc8.0.x tc8.5.x trunk

[Gavin McDonald]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, September 23, 2016 3:25 AM
> To: Tomcat Developers List 
> Subject: Re: [PATCH] - rat-output.xml tweaks for tc8.0.x tc8.5.x trunk
> 
> Gavin,
> 
> On 9/22/16 1:03 AM, Gavin McDonald wrote:
> > Please find attached 3 patches for tweaks to the rat-excludes file in
> > trunk and the 8.0 and 8.5 branches.
> >
> > RAT tests are currently producing invalid xml reports due to files
> > that should be excluded (and therefore xml parser cant convert to html
> > for pretty reports etc)
> >
> > HTH
> >
> > Gav...
> 
> The attachment(s) must have been stripped. 

Yeah I noticed :(

> Would you like to file a BZ issue
> and attach to that?

Sure, not sure what component to put it under. Ideas ?

The patches affect versions 8, 8.5 and trunk , which version do you want me to 
use?

Thanks

Gav...

> 
> -chris



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Introduce methods read/write with ByteBuffer in CoyoteInputStream/CoyoteOutputStream

[Violeta Georgieva]

2016-09-22 18:29 GMT+03:00 Rémy Maucherat :
>
> 2016-09-22 17:13 GMT+02:00 Violeta Georgieva :
>
> > Hi,
> >
> > 2016-09-14 20:43 GMT+03:00 Rémy Maucherat :
> > >
> > > 2016-09-13 20:07 GMT+02:00 Violeta Georgieva :
> > >
> > > > I would like to back port these changes to Tomcat 8.5 if you do not
> > have
> > > > any concerns.
> > > >
> > > > -0.1. I think this is ok, but not certain yet.
> > > - Performance is ok for the "common" unencrypted scenario, but it
could
> > go
> > > down if using SSL, for example [= if the need for direct buffers
could be
> > > hurting - if it is, then there's a problem since SSL will be used
almost
> > > all the time moving forwards].
> >
> > I executed many combinations of performance scenarios - using direct
> > ByteBuffer/non direct ByteBuffer,
> > HTTP/HTTPS, sslImplementationName -
> > org.apache.tomcat.util.net.jsse.JSSEImplementation/org.
> > apache.tomcat.util.net.openssl.OpenSSLImplementation
> > And results with/without my changes are the same.
> > I'm testing with original Tomcat 9.0.0.M9 and Tomcat 9.0.0.M9 + only my
> > changes.
> > I'm testing with blocking and non blocking.
> >
> > Just for testing purposes I changed
> > org.apache.catalina.connector.OutputBuffer
> > to use direct ByteBuffer and then executed SSL scenarios and again the
> > results are the same.
> > No visible performance improvement/degradation.
> >
> > Do you have some scenarios in mind in which a performance degradation
can
> > be experienced.
> > I can test them and take a deeper look.
> >
>
> Ok, good, normally it's the best thing to test. If using OpenSSL, you
> should see better performance with direct buffers though, so maybe there's
> something "wrong" with the testing. If you plan more ByteBuffer use, then
> go ahead and I'll test it.

My idea was to introduce the changes step by step,
because of this I wanted to backport the current changes to Tomcat 8.5 and
receive a feedback.
But if you propose to introduce all ByteBuffer related changes together,
I'm OK and can commit the next changes.
I saw several places where switch to ByteBuffer can be done and I'm going
to finish and commit it.

> >
> >
> > > - I didn't test again after the header processing refactoring (the old
> > code
> > > was there for speed back then in early 2000s, most likely it doesn't
make
> > > any difference now but it could be verified as well).
> >
> > I executed many tests and didn't see any problems.
> >
>
> Yes, I had verified this one already :)

I really appreciate your reviews and testing.

Thanks,
Violeta


> Rémy

Re: [PATCH] - rat-output.xml tweaks for tc8.0.x tc8.5.x trunk

[Christopher Schultz]

Gavin,

On 9/22/16 1:03 AM, Gavin McDonald wrote:
> Please find attached 3 patches for tweaks to the rat-excludes file in trunk
> and the 8.0 and 8.5 branches.
> 
> RAT tests are currently producing invalid xml reports due to files that
> should be excluded 
> (and therefore xml parser cant convert to html for pretty reports etc)
> 
> HTH
> 
> Gav...

The attachment(s) must have been stripped. Would you like to file a BZ
issue and attach to that?

-chris



signature.asc
Description: OpenPGP digital signature

[Bug 60166] According to RFC 6455 the server should reply on a a handshake with "HTTP/1.1 101 Switching Protocols"

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60166

--- Comment #5 from hen...@websolver.dk ---
Mark and Remy

Thanks for your answers.
I will request the library developer for a change. 

Keep up the good Work.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60161] RewriteValve: Add more logging support similar to mod-rewrite

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60161

Remy Maucherat  changed:

   What|Removed |Added

  Attachment #34290|0   |1
is obsolete||

--- Comment #9 from Remy Maucherat  ---
Created attachment 34293
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=34293=edit
Valve logging change

Since the issue is about configuring the valve logging, I have a possible patch
for that. It allows creating subcategories for the container logger, and
exploits the ValveBase.containerLog field to use that other logger.
Not sure if it's really a good idea though.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Introduce methods read/write with ByteBuffer in CoyoteInputStream/CoyoteOutputStream

[Rémy Maucherat]

2016-09-22 17:13 GMT+02:00 Violeta Georgieva :

> Hi,
>
> 2016-09-14 20:43 GMT+03:00 Rémy Maucherat :
> >
> > 2016-09-13 20:07 GMT+02:00 Violeta Georgieva :
> >
> > > I would like to back port these changes to Tomcat 8.5 if you do not
> have
> > > any concerns.
> > >
> > > -0.1. I think this is ok, but not certain yet.
> > - Performance is ok for the "common" unencrypted scenario, but it could
> go
> > down if using SSL, for example [= if the need for direct buffers could be
> > hurting - if it is, then there's a problem since SSL will be used almost
> > all the time moving forwards].
>
> I executed many combinations of performance scenarios - using direct
> ByteBuffer/non direct ByteBuffer,
> HTTP/HTTPS, sslImplementationName -
> org.apache.tomcat.util.net.jsse.JSSEImplementation/org.
> apache.tomcat.util.net.openssl.OpenSSLImplementation
> And results with/without my changes are the same.
> I'm testing with original Tomcat 9.0.0.M9 and Tomcat 9.0.0.M9 + only my
> changes.
> I'm testing with blocking and non blocking.
>
> Just for testing purposes I changed
> org.apache.catalina.connector.OutputBuffer
> to use direct ByteBuffer and then executed SSL scenarios and again the
> results are the same.
> No visible performance improvement/degradation.
>
> Do you have some scenarios in mind in which a performance degradation can
> be experienced.
> I can test them and take a deeper look.
>

Ok, good, normally it's the best thing to test. If using OpenSSL, you
should see better performance with direct buffers though, so maybe there's
something "wrong" with the testing. If you plan more ByteBuffer use, then
go ahead and I'll test it.

>
>
> > - I didn't test again after the header processing refactoring (the old
> code
> > was there for speed back then in early 2000s, most likely it doesn't make
> > any difference now but it could be verified as well).
>
> I executed many tests and didn't see any problems.
>

Yes, I had verified this one already :)

Rémy

[Bug 60166] According to RFC 6455 the server should reply on a a handshake with "HTTP/1.1 101 Switching Protocols"

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60166

Mark Thomas  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Mark Thomas  ---
RFC 2616 is deprecated. That RFC 6455 refers to it does not change that. The
reason phrase is optional in HTTP 1.1.  It won't be added back. Clients that
expect a reason phrase are broken and should be fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Introduce methods read/write with ByteBuffer in CoyoteInputStream/CoyoteOutputStream

[Violeta Georgieva]

Hi,

2016-09-14 20:43 GMT+03:00 Rémy Maucherat :
>
> 2016-09-13 20:07 GMT+02:00 Violeta Georgieva :
>
> > I would like to back port these changes to Tomcat 8.5 if you do not have
> > any concerns.
> >
> > -0.1. I think this is ok, but not certain yet.
> - Performance is ok for the "common" unencrypted scenario, but it could go
> down if using SSL, for example [= if the need for direct buffers could be
> hurting - if it is, then there's a problem since SSL will be used almost
> all the time moving forwards].

I executed many combinations of performance scenarios - using direct
ByteBuffer/non direct ByteBuffer,
HTTP/HTTPS, sslImplementationName -
org.apache.tomcat.util.net.jsse.JSSEImplementation/org.apache.tomcat.util.net.openssl.OpenSSLImplementation
And results with/without my changes are the same.
I'm testing with original Tomcat 9.0.0.M9 and Tomcat 9.0.0.M9 + only my
changes.
I'm testing with blocking and non blocking.

Just for testing purposes I changed
org.apache.catalina.connector.OutputBuffer
to use direct ByteBuffer and then executed SSL scenarios and again the
results are the same.
No visible performance improvement/degradation.

Do you have some scenarios in mind in which a performance degradation can
be experienced.
I can test them and take a deeper look.


> - I didn't test again after the header processing refactoring (the old
code
> was there for speed back then in early 2000s, most likely it doesn't make
> any difference now but it could be verified as well).

I executed many tests and didn't see any problems.

Regards,
Violeta

> Rémy

Re: Introduce methods read/write with ByteBuffer in CoyoteInputStream/CoyoteOutputStream

[Violeta Georgieva]

Hi,

2016-09-14 14:37 GMT+03:00 Mark Thomas :
>
> On 13/09/2016 19:07, Violeta Georgieva wrote:
> > 2016-08-30 15:35 GMT+03:00 Violeta Georgieva :
>
> 
>
> >> I introduced CoyoteOutputStream.write(ByteBuffer) it uses new methods
> >> with ByteBuffer instead of ByteChunk.
> >> Next step is to replace ByteChunk/CharChunk usage in CoyoteOutputStream
> >> with ByteBuffer/CharBuffer thus I will switch to the new methods and
all
> >> CoyoteOutputStream.write method will use them.
> >>
> >
> > I would like to back port these changes to Tomcat 8.5 if you do not have
> > any concerns.
>
> +0.5
>
> I'm a little concerned about destabilising 8.5.x but the CI system looks
> to be doing a good job of catching problems.

In addition to the Tomcat test suite I executed many combinations of
performance tests
 and I do not experience any stability or performance problems with the new
code.

> Generally, I like the direction this is heading in. Reducing copying
> should improve performance but the impact of that doesn't seem to be
> noticeable so far. I do wonder why. Time to add some performance testing
> to my TODO list I think.

Yes I reduced the copy operations, but there is still copy operation when
the socket write buffer is not empty.

> Currently, there are essentially two code paths for read and write.
>
> 1. Original. User facing API uses byte[]. byte[] retained all the way to
> the SocketWrapper where it is copied to ByteBuffer.

The byte[] is wrapped to a ByteBuffer in order to use the new API and when
possible copy is skipped.
org.apache.catalina.connector.OutputBuffer is working with ByteBuffer after
my changes.

> 2. New. User facing API uses ByteBuffer. ByteBuffer retained all the way
> to to the SocketWrapper where it is used if possible or copied to
> another ByteBuffer if not.
>
> I haven't explored this at all so far, but my initial impression is that
> a lot of duplicated functionality could be removed if the original code
> path copied to a ByteBuffer earlier.

Yes my next step is to deprecate and remove the duplicated functionality as
it is not used as I mentioned above.

Regards,
Violeta

> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

[Bug 60166] According to RFC 6455 the server should reply on a a handshake with "HTTP/1.1 101 Switching Protocols"

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60166

--- Comment #3 from Remy Maucherat  ---
Right, I'll let you have fun with your BZ then :) Hopefully you're not
expecting a fix, ever.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60166] According to RFC 6455 the server should reply on a a handshake with "HTTP/1.1 101 Switching Protocols"

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60166

hen...@websolver.dk changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|REOPENED

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60166] According to RFC 6455 the server should reply on a a handshake with "HTTP/1.1 101 Switching Protocols"

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60166

--- Comment #2 from hen...@websolver.dk ---
Hi Remy,

Thanks for the fast answer. I have done some further readings on the RFC 2616
(the HTTP protocol RFC), that is referred to by the RFC 6455.

In section 6.1 it says:
The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and its
associated textual phrase, with each element separated by SP
characters. No CR or LF is allowed except in the final CRLF sequence.

   Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

where SP is a space char, so a valid status line would look like:

HTTP/1.1 101 Switching Protocols

However, the RFC 2616, does not say that the phrase is optional.

Is says in section 6.1.1 is says ".The client is not required to examine or
display the Reason-Phrase".

Which IMO means (to summarize): The server SHOULD make sure that both the
Status-Code and the Reason-Phrase is there, but the client COULD ignore the
Reason-Phrase and operate solely on the Status-Code.

But, as always with RFCs and protocols in general. It depends on the reader.
:-)

Best regards

Henrik

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 47714] Response mixed between users

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=47714

--- Comment #32 from Mark Thomas  ---
Possibly as early as next week. Very likely within the next month. Exact timing
will depend on other demands on my time. Watch the dev list for more info.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 47714] Response mixed between users

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=47714

Philippe Mouawad  changed:

   What|Removed |Added

 Depends on||57485

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60166] According to RFC 6455 the server should reply on a a handshake with "HTTP/1.1 101 Switching Protocols"

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60166

Remy Maucherat  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 OS||All
 Status|NEW |RESOLVED

--- Comment #1 from Remy Maucherat  ---
The reason phrase is optional in HTTP/1.1. The problem IMO is that originally
the websockets spec was written as a binary spec when it dealt with HTTP, it
was a very odd read. Now as I go through the current websockets RFC, it is
clear "Switching Protocols" is not a requirement (4.2.2 - 5 - 1), so things
look better.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 57485] mod_jk passed the incomplete chunked transferred request body to tomcat

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=57485

Philippe Mouawad  changed:

   What|Removed |Added

 Blocks||47714

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60166] New: According to RFC 6455 the server should reply on a a handshake with "HTTP/1.1 101 Switching Protocols"

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60166

Bug ID: 60166
   Summary: According to RFC 6455 the server should reply on a a
handshake with "HTTP/1.1 101 Switching Protocols"
   Product: Tomcat 8
   Version: 8.5.5
  Hardware: PC
Status: NEW
  Severity: major
  Priority: P2
 Component: WebSocket
  Assignee: dev@tomcat.apache.org
  Reporter: hen...@websolver.dk

According to RFC 6455 the server should reply on a a handshake with "HTTP/1.1
101 Switching Protocols"

The status description ("Switching Protocols") is not present in the 8.5.5
release.

Some client libraries rely on the status description ("Switching Protocols") to
be present.
I have tested this on Tomcat 8.0.30 and in that release the description is
present as part of the server's reply on a handshake request from the client.

I don't know if there was some specific reason for not including the
description, however the RFC says iot should be there.

Thanks for your support.

Henrik

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 47714] Response mixed between users

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=47714

--- Comment #31 from Philippe Mouawad  ---
Hello Mark,
What's the expected release date for mod_jk 1.2.42 ?
Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 57485] mod_jk passed the incomplete chunked transferred request body to tomcat

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=57485

Philippe Mouawad  changed:

   What|Removed |Added

 CC||p.mouawad@ubik-ingenierie.c
   ||om

--- Comment #4 from Philippe Mouawad  ---
Hello Mark,
What's the expected release date for mod_jk 1.2.42 ?
Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 47714] Response mixed between users

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=47714

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #30 from Mark Thomas  ---
Having reviewed this ticket, my working theory is that this was caused by bug
57485. It would explain why it was observed with mod_jk but no mod_proxy.

Given that we do not have reproduction steps for this issue I am going to
resolve it as fixed.

If you still see thins issue - or something like in - with mod_jk 1.2.42
onwards please open a new bug and provide as much of the following as possible:
- steps to reproduce from a clean install
- network traces (tmpdump, wireshark etc) for the client <-> httpd link and the
httpd <-> Tomcat link
- mod_jk debug log
- Tomcat and httpd access logs
- Anything else you think might help to track down the root cause.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1761953 - in /tomcat/jk/trunk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml

[markt]

Author: markt
Date: Thu Sep 22 12:56:22 2016
New Revision: 1761953

URL: http://svn.apache.org/viewvc?rev=1761953=rev
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=57485
Apache: Propagate errors reading the request body from the client to mod_jk so 
Tomcat sees an error rather than a truncated body.

Modified:
tomcat/jk/trunk/native/apache-1.3/mod_jk.c
tomcat/jk/trunk/native/apache-2.0/mod_jk.c
tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/jk/trunk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/apache-1.3/mod_jk.c?rev=1761953=1761952=1761953=diff
==
--- tomcat/jk/trunk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/jk/trunk/native/apache-1.3/mod_jk.c Thu Sep 22 12:56:22 2016
@@ -428,7 +428,7 @@ static int JK_METHOD ws_read(jk_ws_servi
 if (p->read_body_started) {
 long rv;
 if ((rv = ap_get_client_block(p->r, b, len)) < 0) {
-*actually_read = 0;
+return JK_FALSE;
 }
 else {
 *actually_read = (unsigned)rv;

Modified: tomcat/jk/trunk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/apache-2.0/mod_jk.c?rev=1761953=1761952=1761953=diff
==
--- tomcat/jk/trunk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/jk/trunk/native/apache-2.0/mod_jk.c Thu Sep 22 12:56:22 2016
@@ -463,7 +463,7 @@ static int JK_METHOD ws_read(jk_ws_servi
 #endif
 
 if ((rv = ap_get_client_block(p->r, b, len)) < 0) {
-*actually_read = 0;
+return JK_FALSE;
 }
 else {
 *actually_read = (unsigned)rv;

Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=1761953=1761952=1761953=diff
==
--- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Thu Sep 22 12:56:22 2016
@@ -55,6 +55,11 @@
 failed during earlier processing phases. (rjung)
   
   
+57485: Apache: Propagate errors reading the request body 
from
+the client to mod_jk so Tomcat sees an error rather than a truncated
+body. (markt) 
+  
+  
 57836: ISAPI: Empty REMOTE_USER should not be
 translated to "". (rjung)
   



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 57485] mod_jk passed the incomplete chunked transferred request body to tomcat

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=57485

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Mark Thomas  ---
Thanks for the report. This has been fixed in trunk for 1.2.42 onwards.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1761893 - in /tomcat/native/trunk: native/srclib/VERSIONS xdocs/miscellaneous/changelog.xml

[markt]

Author: markt
Date: Thu Sep 22 11:02:43 2016
New Revision: 1761893

URL: http://svn.apache.org/viewvc?rev=1761893=rev
Log:
Update the minimum recommended OpenSSL version due to known issues with 1.0.2h

Modified:
tomcat/native/trunk/native/srclib/VERSIONS
tomcat/native/trunk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/native/trunk/native/srclib/VERSIONS
URL: 
http://svn.apache.org/viewvc/tomcat/native/trunk/native/srclib/VERSIONS?rev=1761893=1761892=1761893=diff
==
--- tomcat/native/trunk/native/srclib/VERSIONS (original)
+++ tomcat/native/trunk/native/srclib/VERSIONS Thu Sep 22 11:02:43 2016
@@ -1,4 +1,4 @@
 Use the following version of the libraries
 
 - APR 1.5.2, http://apr.apache.org
-- OpenSSL 1.0.2h or later, http://www.openssl.org
+- OpenSSL 1.0.2i or later, http://www.openssl.org

Modified: tomcat/native/trunk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/native/trunk/xdocs/miscellaneous/changelog.xml?rev=1761893=1761892=1761893=diff
==
--- tomcat/native/trunk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/native/trunk/xdocs/miscellaneous/changelog.xml Thu Sep 22 11:02:43 
2016
@@ -36,6 +36,11 @@
 
 
   
+  
+
+  Update minimum recommended OpenSSL version to 1.0.2i. (markt)
+
+  
   
 
 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60100] Garbage appended at end of request URL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60100

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #4 from Mark Thomas  ---
Restoring the NEEDINFO state. Comment #1 has a number of unanswered questions.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60100] Garbage appended at end of request URL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60100

Andrea Giovacchini  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60100] Garbage appended at end of request URL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60100

--- Comment #3 from Andrea Giovacchini  ---
(In reply to Konstantin Kolinko from comment #2)

Hi, the request were coming from valid clients, I was doing them with one of
our applications and no one else was calling, it's a test environment in a
private network.

I can't see what the %{User-Agent} will print if added to logging because the
problem disappeared after restarting Tomcat and the has been no way I was able
to reproduce it again.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60164] New: Add log4j-web*.jar to tomcat.util.scan.StandardJarScanFilter.jarsToScan

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60164

Bug ID: 60164
   Summary: Add log4j-web*.jar to
tomcat.util.scan.StandardJarScanFilter.jarsToScan
   Product: Tomcat 8
   Version: 8.5.5
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: bal...@gmail.com

log4j-web.jar actually contains relevant servlet container configuration
information (web-fragment.xml and services/ServletContainerInitializer), yet it
is covered by jarsToSkip as log4j*.jar. Please add log4j-web*.jar to jarsToScan
override. 

https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-web

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60161] RewriteValve: Add more logging support similar to mod-rewrite

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60161

--- Comment #8 from Remy Maucherat  ---
(In reply to Santhana Preethi from comment #6)
> > Now so? I would think this might be the one good part of this proposed
> > patch, because it makes it easier to adjust the log level of *only* the
> > RewriteValve. 
> 
> As Christopher pointed out, this would make it easier to configure log level
> for RewriteValve. 

That's his opinion and I happen to disagree with it. You can configure the log
level of the container.
I also don't see what the processing time is used for in a sub component, this
screams like a feature from 15 years ago [use a debugger instead].

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GUMP@vmgump]: Project tomcat-trunk-test-apr (in module tomcat-trunk) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-trunk-test-apr has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 3 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-trunk-test-apr :  Tomcat 9.x, a web server implementing the Java 
Servlet 4.0,
...


Full details are available at:

http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-apr/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on commons-daemon exists, no need to add for property 
commons-daemon.native.src.tgz.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property 
tomcat-native.tar.gz.
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-trunk/output/logs-APR
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-trunk/output/test-tmp-APR/logs
 -WARNING- No directory 
[/srv/gump/public/workspace/tomcat-trunk/output/test-tmp-APR/logs]



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-apr/gump_work/build_tomcat-trunk_tomcat-trunk-test-apr.html
Work Name: build_tomcat-trunk_tomcat-trunk-test-apr (Type: Build)
Work ended in a state of : Failed
Elapsed: 28 mins 54 secs
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only org.apache.tools.ant.Main 
-Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dbase.path=/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs 
-Dtest.temp=output/test-tmp-APR 
-Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar 
-Dtest.accesslog=true 
-Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.5-SNAPSHOT.jar
 -Dexamples.sources.skip=true 
-Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20160922.jar
 
-Dtest.openssl.path=/srv/gump/public/workspace/openssl-master/dest-20160922/bin/openssl
 -Dexecute.test.nio=false 
-Dhamcrest.jar=/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar 
-Dexecute.test.apr=true -Dexecute.test.nio2=false 
-Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20160922-native-src.tar.gz
 -Dtest.reports=output/logs-APR -Dtomc
 
at-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20160922-native-src.tar.gz
 -Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.5-201506032000/ecj-4.5.jar 
-Dtest.apr.loc=/srv/gump/public/workspace/tomcat-native-trunk/dest-20160922/lib 
-Dtest.relaxTiming=true -Dtest.excludePerformance=true 
-Djava.net.preferIPv4Stack=/srv/gump/public/workspace/tomcat-trunk/true 
-Deasymock.jar=/srv/gump/public/workspace/easymock/core/target/easymock-3.5-SNAPSHOT.jar
 -Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test 
[Working Directory: /srv/gump/public/workspace/tomcat-trunk]
CLASSPATH: 
/usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.ja
 
r:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jaspic-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-storeconfig.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat

[Bug 60161] RewriteValve: Add more logging support similar to mod-rewrite

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60161

Santhana Preethi  changed:

   What|Removed |Added

  Attachment #34287|0   |1
is obsolete||

--- Comment #7 from Santhana Preethi  ---
Created attachment 34290
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=34290=edit
Modified patch for Rewrite Logging

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60161] RewriteValve: Add more logging support similar to mod-rewrite

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60161

--- Comment #6 from Santhana Preethi  ---
(In reply to Mark Thomas from comment #2)

> The switch from the container's logger to a dedicated Rewrite logger is
> problematic too.

I don't think writing all rewrite logs to container's logger is a good idea. In
the current situation, adjusting container's logger level to DEBUG is required
to write rewrite logs. 

(In reply to Christopher Schultz from comment #3)

> Now so? I would think this might be the one good part of this proposed
> patch, because it makes it easier to adjust the log level of *only* the
> RewriteValve. 

As Christopher pointed out, this would make it easier to configure log level
for RewriteValve. 

(In reply to Mark Thomas from comment #2)

> There might be a case for recording the time taken to rewrite the URL but a)
> it should only be collected and logged when debug logging is enabled and b)
> should use nanoTime.

I've reworked the patch with log levels DEBUG,TRACE and nanoTime. I've
replicated httpd mod_rewrite logging behaviour where level 2 logs only the
rewrite information and level 3 also logs all the rules that were applied
before the rewrite happened.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org