You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by re...@apache.org on 2008/09/25 15:21:15 UTC
svn commit: r698960 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: remm
Date: Thu Sep 25 06:21:15 2008
New Revision: 698960
URL: http://svn.apache.org/viewvc?rev=698960&view=rev
Log:
- Votes.
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=698960&r1=698959&r2=698960&view=diff
==============================================================================
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Sep 25 06:21:15 2008
@@ -146,20 +146,24 @@
* More EL fixes. Add lookaheads to prevent parsing ambiguity
http://svn.apache.org/viewvc?rev=696780&view=rev (the change)
http://svn.apache.org/viewvc?rev=696782&view=rev (the auto generated code)
- +1: mark
+ +1: mark, remm
-1:
* Correct wrong "No role found" debug message,
logged in RealmBase even if a role was found.
http://svn.apache.org/viewvc?rev=697158&view=rev
- +1: rjung, mturk, markt
+ +1: rjung, mturk, markt, remm
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45026
Never use empty reason phrase.
http://svn.apache.org/viewvc?rev=697183&view=rev
+1: rjung, mturk, markt
- -1:
+ -1: remm (I think HttpMessages.getMessage should return something rather than null,
+ most likely something like sc.ZZZ like you are doing, otherwise you need to fix
+ the APR implementation as well;
+ if I understand correctly, trouble will occur with AJP if status is something 467,
+ with no message set)
* Allow huge request body packets for AJP13.
This was already applied to connectors, but never
@@ -167,32 +171,34 @@
http://svn.apache.org/viewvc?rev=697192&view=rev
Original change: http://svn.apache.org/viewvc?rev=486217&view=rev
+1: rjung, mturk, markt
- -1:
+ -1: remm (- bodyMsg.appendInt(AjpConstants.MAX_READ_SIZE + packetSize - AjpConstants.MAX_PACKET_SIZE); looks wrong
+ - also partially applies to the two other AJP connectors
+ - not sure why forcing AjpConstants.MAX_PACKET_SIZE; either this shouldn't be done or the constant name should change)
* Remove admin app from logging configuration
http://svn.apache.org/viewvc?rev=698012&view=rev
- +1: markt, rjung
+ +1: markt, rjung, remm
-1:
* Add CombinedRealm and LockOutRealm with docs
http://people.apache.org/~markt/patches/2008-09-24-lockout-realm.patch
- +1: markt
+ +1: markt, remm (but you should stop adding features at some point)
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45852
Add special handing to the Windows installer for a charset that doesn't follow
the standard naming convention
http://svn.apache.org/viewvc?rev=698613&view=rev
- +1: markt, mturk
+ +1: markt, mturk, remm (arg, hack)
-1:
* Update tc-native to lastest version:
http://people.apache.org/~jfclere/patches/patch.new-tcnative
- +1: jclere, markt
+ +1: jclere, markt, remm
-1:
* Backport "Remove unused code" in ELSupport.java.
Keeps trunk and tc6 in sync and is no risk.
http://svn.apache.org/viewvc?rev=649637&view=rev
- +1: rjung, markt
+ +1: rjung, markt, remm (but cosmetic changes should stop in this branch)
-1:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r698960 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Remy Maucherat <re...@apache.org>.
On Thu, 2008-09-25 at 18:15 +0200, Rainer Jung wrote:
> Sorry Rémy, I don't understand you. packetSize is always >=
> MAX_PACKET_SIZE and MAX_PACKET_SIZE is fixed at 8192.
>
> The above formula is equivalent to
>
> packetSize - whatever_the_header_length_is
>
> which itself is >= MAX_PACKET_SIZE - whatever_the_header_length_is.
>
> That sounds strange, but as I mentioned, MAX_PACKET_SIZE is no longer
> the maximum. It is the default maximum, which can be increased by
> configuration.
Ok, so it's really the same thing, only more complex, you should have
noted it packetSize - header_length.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r698960 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Rainer Jung <ra...@kippdata.de>.
>>> * Allow huge request body packets for AJP13.
>>> This was already applied to connectors, but never
>>> @@ -167,32 +171,34 @@
>>> http://svn.apache.org/viewvc?rev=697192&view=rev
>>> Original change: http://svn.apache.org/viewvc?rev=486217&view=rev
>>> +1: rjung, mturk, markt
>>> - -1:
>>> + -1: remm (- bodyMsg.appendInt(AjpConstants.MAX_READ_SIZE + packetSize - AjpConstants.MAX_PACKET_SIZE); looks wrong
>> Before the change it was simply MAX_READ_SIZE. After the change, if our
>> actual configured maximum packet size (A=packetSize) is bigger or
>> smaller than the default one (B=MAX_PACKET_SIZE) we adjust the read size
>> accordingly by the delta A-B.
>>
>> Phrased diffferentyl:
>>
>> MAX_READ_SIZE = MAX_PACKET_SIZE - H_SIZE - 2;
>>
>> So
>>
>> MAX_READ_SIZE + packetSize - MAX_PACKET_SIZE =
>> MAX_PACKET_SIZE - H_SIZE - 2 + packetSize - MAX_PACKET_SIZE =
>> packetSize -H_SIZE - 2
>
> In your code there is packetSize <=> MAX_PACKET_SIZE. I had
> MAX_READ_SIZE = MAX_PACKET_SIZE - whatever_the_header_length_is, so I
> don't see how it should not become MAX_READ_SIZE <=> packetSize -
> whatever_the_header_length_is.
Sorry Rémy, I don't understand you. packetSize is always >=
MAX_PACKET_SIZE and MAX_PACKET_SIZE is fixed at 8192.
The above formula is equivalent to
packetSize - whatever_the_header_length_is
which itself is >= MAX_PACKET_SIZE - whatever_the_header_length_is.
That sounds strange, but as I mentioned, MAX_PACKET_SIZE is no longer
the maximum. It is the default maximum, which can be increased by
configuration.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r698960 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Remy Maucherat <re...@apache.org>.
On Thu, 2008-09-25 at 16:49 +0200, Rainer Jung wrote:
> So you propose to move the fix simply to HttpMessages.getMessage, which
> should return with status code as string, whenever the StringManager
> doesn't find a reason phrase. Correct?
The benefit is that it would fix the 3 connectors with one patch. The
"drawback" is that it always generates a message.
> > * Allow huge request body packets for AJP13.
> > This was already applied to connectors, but never
> > @@ -167,32 +171,34 @@
> > http://svn.apache.org/viewvc?rev=697192&view=rev
> > Original change: http://svn.apache.org/viewvc?rev=486217&view=rev
> > +1: rjung, mturk, markt
> > - -1:
> > + -1: remm (- bodyMsg.appendInt(AjpConstants.MAX_READ_SIZE + packetSize - AjpConstants.MAX_PACKET_SIZE); looks wrong
>
> Before the change it was simply MAX_READ_SIZE. After the change, if our
> actual configured maximum packet size (A=packetSize) is bigger or
> smaller than the default one (B=MAX_PACKET_SIZE) we adjust the read size
> accordingly by the delta A-B.
>
> Phrased diffferentyl:
>
> MAX_READ_SIZE = MAX_PACKET_SIZE - H_SIZE - 2;
>
> So
>
> MAX_READ_SIZE + packetSize - MAX_PACKET_SIZE =
> MAX_PACKET_SIZE - H_SIZE - 2 + packetSize - MAX_PACKET_SIZE =
> packetSize -H_SIZE - 2
In your code there is packetSize <=> MAX_PACKET_SIZE. I had
MAX_READ_SIZE = MAX_PACKET_SIZE - whatever_the_header_length_is, so I
don't see how it should not become MAX_READ_SIZE <=> packetSize -
whatever_the_header_length_is.
> > + - not sure why forcing AjpConstants.MAX_PACKET_SIZE; either this shouldn't be done or the constant name should change)
>
> The constant MAX_PACKET_SIZE is equal to the previous value of 8192. If
> one wants to use another size, there is another constructor, which
> inlcudes the size and sets it correctly. This one here is deprecated,
> but for me the reason why the 8192 was there, was that it's the usual
> AJP packet size. Since we already had a constant for that, I replaced it.
>
> Yes the name of the constant doesn't reflect it's use now in all places.
> It is the DEFAULT_MAX_PACKET_SIZE. At the moment there seems to be no
> maximum enforced (with the patch), but there is one (implementation
> dependant) on the client (native) side, and if you use non-default
> values, you need to keep them in sync on the two sides.
>
> Do you think we should rename MAX_PACKET_SIZE to DEFAULT_MAX_PACKET_SIZE?
I am tired of hearing about AJP problems.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r698960 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Rainer Jung <ra...@kippdata.de>.
> * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45026
> Never use empty reason phrase.
> http://svn.apache.org/viewvc?rev=697183&view=rev
> +1: rjung, mturk, markt
> - -1:
> + -1: remm (I think HttpMessages.getMessage should return something rather than null,
> + most likely something like sc.ZZZ like you are doing, otherwise you need to fix
> + the APR implementation as well;
> + if I understand correctly, trouble will occur with AJP if status is something 467,
> + with no message set)
So you propose to move the fix simply to HttpMessages.getMessage, which
should return with status code as string, whenever the StringManager
doesn't find a reason phrase. Correct?
> * Allow huge request body packets for AJP13.
> This was already applied to connectors, but never
> @@ -167,32 +171,34 @@
> http://svn.apache.org/viewvc?rev=697192&view=rev
> Original change: http://svn.apache.org/viewvc?rev=486217&view=rev
> +1: rjung, mturk, markt
> - -1:
> + -1: remm (- bodyMsg.appendInt(AjpConstants.MAX_READ_SIZE + packetSize - AjpConstants.MAX_PACKET_SIZE); looks wrong
Before the change it was simply MAX_READ_SIZE. After the change, if our
actual configured maximum packet size (A=packetSize) is bigger or
smaller than the default one (B=MAX_PACKET_SIZE) we adjust the read size
accordingly by the delta A-B.
Phrased diffferentyl:
MAX_READ_SIZE = MAX_PACKET_SIZE - H_SIZE - 2;
So
MAX_READ_SIZE + packetSize - MAX_PACKET_SIZE =
MAX_PACKET_SIZE - H_SIZE - 2 + packetSize - MAX_PACKET_SIZE =
packetSize -H_SIZE - 2
> + - also partially applies to the two other AJP connectors
I'll look for that.
> + - not sure why forcing AjpConstants.MAX_PACKET_SIZE; either this shouldn't be done or the constant name should change)
The constant MAX_PACKET_SIZE is equal to the previous value of 8192. If
one wants to use another size, there is another constructor, which
inlcudes the size and sets it correctly. This one here is deprecated,
but for me the reason why the 8192 was there, was that it's the usual
AJP packet size. Since we already had a constant for that, I replaced it.
Yes the name of the constant doesn't reflect it's use now in all places.
It is the DEFAULT_MAX_PACKET_SIZE. At the moment there seems to be no
maximum enforced (with the patch), but there is one (implementation
dependant) on the client (native) side, and if you use non-default
values, you need to keep them in sync on the two sides.
Do you think we should rename MAX_PACKET_SIZE to DEFAULT_MAX_PACKET_SIZE?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org