494433674
|--- |INVALID
OS||All
--- Comment #1 from Chuck Caldarale ---
Bugzilla is not a playground.
--
You are receiving this mail because:
You are the assignee for the bug
Hi folks,
currenly we have a minimalistic ASN.1 parser in the code tree w/o any
testing since it assumes that the passed byte array is properly encoded.
Now, I do have some X.509 related improvements which I'd like to bring
upstream from my OSS project which I think will benefit eve
code is organized in several relatively independent components, some of
them low-risk, some controversial -
I will start a separate thread with a proposal to merge back the first
component, then decide what to do with the
others based on the feedback I get here.
1. General tomcat-util and c
https://issues.apache.org/bugzilla/show_bug.cgi?id=55803
Bug ID: 55803
Summary: 1
Product: Tomcat Connectors
Version: 1.2.37
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: mod_jk
Hi,
Tomcat 7 depends on DBCP 1.x and POOL 1.x. The last release of each of
these was in 2013. There are a number of fixes I would like to be able
to pull into Tomcat 7 - including the fix for BZ 58338.
There is little/no appetite in the Commons community to release DBCP 1.x
or Pool 1.x.
Having
Greetings!
JDK 19 has now entered Rampdown Phase One (RDP1) [1], which means that
the main-line has been forked into a dedicated JDK 19 stabilization
repository. At this point, the overall JDK 19 feature set is frozen and
no additional JEPs will be targeted to JDK 19. The stabilization
https://bz.apache.org/bugzilla/show_bug.cgi?id=51813
--- Comment #13 from Steve Kirk ---
Updated versions of everything.
http://happy-wheelsgames.com/
--
You are receiving this mail because:
You are the assignee for the bug.
-
https://issues.apache.org/bugzilla/show_bug.cgi?id=51813
--- Comment #12 from Jackie Rosen ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bug
https://issues.apache.org/bugzilla/show_bug.cgi?id=51813
--- Comment #4 from Christopher Schultz ---
We have another bite:
http://markmail.org/message/f5idaje4a4vg7vkd
Updated versions of everything, but the symptom is the same: ImageIO bug + APR
+ sendbb() + si_addr=0x0040
--
You
https://issues.apache.org/bugzilla/show_bug.cgi?id=51813
--- Comment #5 from Christopher Schultz ---
I think this ought to do it (though I'm sure there are other places in tcnative
that could afford to have this same kind of checking):
Index: native/src/network.c
===
https://issues.apache.org/bugzilla/show_bug.cgi?id=51813
--- Comment #6 from Christopher Schultz ---
(Note the above example patch is against tcnative/1.1.x branch)
--
You are receiving this mail because:
You are the assignee for the bug.
---
https://issues.apache.org/bugzilla/show_bug.cgi?id=51813
--- Comment #7 from Christopher Schultz ---
Created attachment 30402
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30402&action=edit
Patch against tcnative-1.1.x
I'm not sure if I should be checking s->net or s->sock. They bot
https://issues.apache.org/bugzilla/show_bug.cgi?id=51813
--- Comment #8 from Rainer Jung ---
(In reply to Christopher Schultz from comment #7)
> Created attachment 30402 [details]
> Patch against tcnative-1.1.x
>
> I'm not sure if I should be checking s->net or s->sock. They both seem to be
> se
https://issues.apache.org/bugzilla/show_bug.cgi?id=51813
--- Comment #9 from Christopher Schultz ---
(In reply to Rainer Jung from comment #8)
> (In reply to Christopher Schultz from comment #7)
> > Created attachment 30402 [details]
> > Patch against tcnative-1.1.x
> >
> > I'm not sure if I sho
0.0.1-auto-1"]
[junit] Aug 02, 2013 2:52:52 PM org.apache.catalina.core.StandardService
startInternal
[junit] INFO: Starting service Tomcat
[junit] Aug 02, 2013 2:52:52 PM org.apache.catalina.core.StandardEngine
startInternal
[junit] INFO: Starting Servlet Engine: Apache T
https://issues.apache.org/bugzilla/show_bug.cgi?id=51813
Christopher Schultz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bz.apache.org/bugzilla/show_bug.cgi?id=51813
Mark Thomas changed:
What|Removed |Added
CC||tanaka.shuns...@simplex.ne.
On 03/05/2024 08:17, Michael Osipov wrote:
Hi folks,
currenly we have a minimalistic ASN.1 parser in the code tree w/o any
testing
The ASN.1 parsing is covered by the test suite.
since it assumes that the passed byte array is properly encoded.
Correct. For the Tomcat use case it is
On 2024/05/03 08:59:17 Mark Thomas wrote:
>
>
> On 03/05/2024 08:17, Michael Osipov wrote:
> > Hi folks,
> >
> > currenly we have a minimalistic ASN.1 parser in the code tree w/o any
> > testing
>
> The ASN.1 parsing is covered by the test suite.
My ba
On 03/05/2024 11:01, Michael Osipov wrote:
On 2024/05/03 08:59:17 Mark Thomas wrote:
There have been discussions about a new tomcat-shaded JAR that would
provide all the shaded dependencies we use both internally and with the
migration tool. My general concern with that is the volume of code
eds to be retired or moved out.
>
> The code is organized in several relatively independent components, some of
> them low-risk, some controversial -
> I will start a separate thread with a proposal to merge back the first
> component, then decide what to do with the
> others based
>> If you read this far - I don't want to start a flame war, but I appreciate
>> all feedback :-). My current goal is to
>> 'graduate' the first 2 components, the others can stay longer in sandbox or
>> be moved out - but since they rely on
>> the first 2 I would have to clone a lot of tomcat code
I for one happen to think this is a great idea (generally).
More specifically, for at least one small web application (where Tomcat is
stripped down and embedded), I have been tempted to strip out the servlet
support code (for a number of reasons).
On Sat, Aug 30, 2008 at 12:13 AM, Costin Manolache <[EMAIL PROTECTED]> wrote:
> and easier to embed variant. I think it's time to see what can be
> contributed back to tomcat main branch, what can be
> released, and what needs to be retired or moved out.
Overall, a huge +1.
On Fri, 2008-08-29 at 21:13 -0700, Costin Manolache wrote:
> I think moving forward, for tomcat-7 and beyond - it would be worth
> reconsidering some of the 10-year-old decisions, and
> tomcat-lite can be a good example on how things can be done
differently:
I still don't intend to participate in
Remy Maucherat wrote:
I am interested to look at the code like the proxy, and see if what it
can do.
I have been longing for a Java-based load-balancing proxy replacement
for Apache httpd. Essentially with non-blocking IO it would seem high
time to replace Apache httpd with a Java-based web
Thanks for all the answers so far - I'll start a new thread for the first
part of the process,
with more details on the coyote changes. The help I need most is review and
comments
from people who spent most time with coyote. The goal of tomcat-lite is to
be small and simple -
hopefully it wont have
On Sat, 2008-08-30 at 20:44 -0700, Costin Manolache wrote:
> > > - Valves/LifecycleListeners versus plain Filters and listeners
> >
> > Personally, I think the strong type barrier between userland and the
> > container is nice.
> >
>
> Access to low-level container objects ( which is the 'barrier'
Costin Manolache wrote:
Cool. In a nutshell - I like all the ideas.
But while I like the idea of ditching Valves/LifecycleListeners - how
does this work when the component needs to work across multiple
ServletContext's? The only reason I see that Valves/LifecycleListeners
need to yet exist
On Tue, Sep 2, 2008 at 3:57 AM, Tim Funk <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
>
>>
>>
>
> Cool. In a nutshell - I like all the ideas.
>
> But while I like the idea of ditching Valves/LifecycleListeners - how does
> this work when the component needs to work across multiple Servlet
ter.
About Valves versus Filters.. I don't see the advantages of using
Filters in the container instead of Valves. Here are some reasons
I've heard for either completely removing Valves, or for using
something else instead of Valves, and my thoughts on each:
Reason 1: Valves complicate the c
gular features and
> compatibility packaged as a jar file would be worth it. If it could
> be possible to make the jar file smaller (by offering build-time
> subsetting maybe? with popular subset jars up for download?), while
> still maintaining a high degree of compatibility wit
Only two changes,
1. Correct version of NSIS was used
2. Updated release notes
http://people.apache.org/~fhanik/v5.5.18-beta-1/
Servlet TCK ran through fine. JSP tck is still running.
Filip
-
To unsubscribe, e-mail: [EMAIL
On Tue, Feb 12, 2019 at 2:55 PM Mark Thomas wrote:
> Hi,
>
> Tomcat 7 depends on DBCP 1.x and POOL 1.x. The last release of each of
> these was in 2013. There are a number of fixes I would like to be able
> to pull into Tomcat 7 - including the fix for BZ 58338.
>
> There
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 2/12/19 08:55, Mark Thomas wrote:
> Hi,
>
> Tomcat 7 depends on DBCP 1.x and POOL 1.x. The last release of each
> of these was in 2013. There are a number of fixes I would like to
> be able to pull into Tomcat 7 - including
On 12/02/2019 23:10, Christopher Schultz wrote:
> Mark,
>
> On 2/12/19 08:55, Mark Thomas wrote:
>> Hi,
>
>> Tomcat 7 depends on DBCP 1.x and POOL 1.x. The last release of each
>> of these was in 2013. There are a number of fixes I would like to
>> be able t
enforce 1-2-1 mapping for request and InputBuffer
---
.../org/apache/catalina/connector/InputBuffer.java | 28 +++---
java/org/apache/catalina/connector/Request.java| 9 ---
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/java/org/apache/catalina/connector
-javax.el.TestImportHandlerStandardPackages.NIO2.txt
Testsuite: javax.el.TestImportHandlerStandardPackages
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.35 sec
Testcase: testClassListsAreComplete took 0.326 sec
FAILED
java.lang.MatchException
junit.framework.AssertionFailedError: java.lang.MatchException
On 14/06/2022 09:00, Martin Grigorov wrote:
Hello Tomcat devs,
The following test fails with JDK 19 b26:
[concat] Testsuites with failed tests:
[concat] TEST-javax.el.TestImportHandlerStandardPackages.APR.txt
[concat] TEST-javax.el.TestImportHandlerStandardPackages.NIO.txt
[con
On Tue, Jun 14, 2022 at 3:07 PM Mark Thomas wrote:
>
>
> On 14/06/2022 09:00, Martin Grigorov wrote:
> > Hello Tomcat devs,
> >
> > The following test fails with JDK 19 b26:
> >
> > [concat] Testsuites with failed tests:
> > [concat] TEST-javax.el.TestImportHandlerStandardPackages.APR.txt
>
Martin,
On 6/14/22 14:42, Martin Grigorov wrote:
On Tue, Jun 14, 2022 at 3:07 PM Mark Thomas wrote:
On 14/06/2022 09:00, Martin Grigorov wrote:
Hello Tomcat devs,
The following test fails with JDK 19 b26:
[concat] Testsuites with failed tests:
[concat] TEST-javax.el.TestImportHan
On Tue, Jun 14, 2022 at 10:08 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Martin,
>
> On 6/14/22 14:42, Martin Grigorov wrote:
> > On Tue, Jun 14, 2022 at 3:07 PM Mark Thomas wrote:
> >
> >>
> >>
> >> On 14/06/2022 09:00, Martin Grigorov wrote:
> >>> Hello Tomcat devs,
> >>>
>
Hi David,
Apache Tomcat's build and tests pass successfully with JDK 19-ea+26-2060
and 20-ea+1-3 on Linux x86_64 and aarch64!
Regards,
Martin
On Tue, Jun 14, 2022 at 11:00 AM Martin Grigorov
wrote:
> Hello Tomcat devs,
>
> The following test fails with JDK 19 b26:
>
>
enforce 1-2-1 mapping for request and Coyote request
---
java/org/apache/catalina/connector/Connector.java | 12 +++-
.../apache/catalina/connector/CoyoteAdapter.java | 6 +-
java/org/apache/catalina/connector/Request.java| 27 -
.../TesterDigestAuthenticatorPerformance.java | 2
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
--- Comment #1 from linking12 <297442...@qq.com> ---
3: hpack decode error, headerName: device-info, value: �
device-info is a base64 string
--
You are receiving this mail because:
You are the assignee for t
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
--- Comment #2 from Thomas ---
The original exception stack trace is as below in Tomcat source:
java.lang.NegativeArraySizeException: -1
at
java.base/java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:86)
at java.base
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
Mark Thomas changed:
What|Removed |Added
Severity|critical|enhancement
--- Comment #3 from Mark Tho
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
--- Comment #4 from linking12 <297442...@qq.com> ---
this is issue happen on prod env, It diffcult to reproduce.
some request is ok, but some request is error;
it is very difficult to reproduce, and tcpdump also difficult.
the purpose of submit
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
--- Comment #5 from gr...@webtide.com ---
Mark, I can't tell either if this is Jetty encoding or Tomcat decoding.
If you want to write a test to do some jetty encodes and tomcate decodes, then
if you have a maven dependency on org.eclipse.jet
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
--- Comment #6 from Thomas ---
I found some information. Can you give me some answers?
1. If my header size is very big. Its length is bigger than 1024 after huffman
encoding, the header will not be got.
2. The value of the variable "l
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
--- Comment #7 from Thomas ---
(In reply to Thomas from comment #6)
> I found some information. Can you give me some answers?
> 1. If my header size is very big. Its length is bigger than 1024 after
> huffman encoding, the header wi
onseReceived =
> (Response)decoder.decode(buffer);
>
> System.err.println(responseReceived);
> responseReceived.getFields().stream().forEach(System.err::println);
> }
I have test your code, It is ok
but we do something,and found more information，when the header i
4, the headerReadBuffer can not expand;
i confirm jetty encode right; we confirm from this order:
1: disable hpack index in jetty and Huffman, force header encode by Ascii
2: force header larger than 1k
3: debug tomcat decode and found can not process the header(larger than 1k)
--
You are receiving thi
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
linking12 <297442...@qq.com> changed:
What|Removed |Added
Priority|P2 |P1
Severity|en
.Http2Parser#headerReadBuffer,
then the return value of org.apache.coyote.http2.Hpack#decodeInteger will be
-1. And then the exception "java.lang.NegativeArraySizeException: -1" is thrown
in org.apache.coyote.http2.HpackDecoder#readHpackString, because the length is
-1.
Reproduce steps:
examp
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
--- Comment #11 from Remy Maucherat ---
This is correct, the original code has the fix now. I'll do that.
--
You are receiving this mail because:
You are the assignee for the bug.
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
Remy Maucherat changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
--- Comment #13 from Joakim Erdfelt ---
Does this HPACK fix also address the HPACK index issue reported (at the Jetty
issue tracker) against Tomcat?
https://github.com/eclipse/jetty.project/issues/6341
--
You are receiving this mail because:
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
--- Comment #14 from Thomas ---
I think they are not the same issue. The issue you mentioned above is also
submitted by me. The same time, I had submitted the same one in tomcat as
follow:
https://bz.apache.org/bugzilla/show_bug.cgi?id=65350
P
Hello,
I just noticed those following messages in my apache log files, and
wasn't able to find the cause. Any documentations/insights for those
error messages?
[error] channelSocket.receive(): Error receiving message body -1 2
[error] workerEnv.processCallbacks() Error reading reply
[
Hi All,
What is the status of this issue?
https://issues.apache.org/bugzilla/show_bug.cgi?id=41263
I am interested in this because NTLMSSP authentication is basically
not possible unless the remote port is accessible and I want people to
be able to use my product through Apache if possible.
T
https://issues.apache.org/bugzilla/show_bug.cgi?id=50030
Tim Whittington changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
and JSP tck went through fine
Filip
Filip Hanik - Dev Lists wrote:
Only two changes,
1. Correct version of NSIS was used
2. Updated release notes
http://people.apache.org/~fhanik/v5.5.18-beta-1/
Servlet TCK ran through fine. JSP tck is still running.
Filip
let me know if you get a chance to check it out, we can then announce it
as a beta, and then after some time vote for its stability. is that the
correct order?
Filip
Filip Hanik - Dev Lists wrote:
and JSP tck went through fine
Filip
Filip Hanik - Dev Lists wrote:
Only two changes,
1
Hi,
A couple more things:
1. The KEYS file doesn't have your PGP key used to sign the release,
and that's a showstopper ;)
2. The changelog still lists me as the release manager, feel free to
update it to yourself.
Other than that, looks good to
with the RM posting a release in a non-official
location and announcing it on the dev list, as you have, people
testing that release, a stability vote here, and then a formal release
announcement coupled with the distributions placed in an official
location for mirroring.
Yoav
On 9/1/06, Filip
Yoav Shapira wrote:
Hi,
A couple more things:
1. The KEYS file doesn't have your PGP key used to sign the release,
and that's a showstopper ;)
it does have the key, just not the extra info in between, I'll add that.
2. The changelog still lists me as the release manager, feel
2006/9/1, Yoav Shapira <[EMAIL PROTECTED]>:
Hi,
In the past, the RM announced the release publicly with his/her
perception of quality, and we had a stability vote after some time.
Following some discussions on this mailing list over the past few
months, I think we've decided to chang
we are still doing it the old way, no code would change in the same tag
Filip
Erik Bertelsen wrote:
2006/9/1, Yoav Shapira <[EMAIL PROTECTED]>:
Hi,
In the past, the RM announced the release publicly with his/her
perception of quality, and we had a stability vote after some time.
Fol
2006/9/2, Filip Hanik - Dev Lists <[EMAIL PROTECTED]>:
we are still doing it the old way, no code would change in the same tag
Filip
Ok, if that is the case, then I probably don't have to worry about the fact
that the distribution file may change a few times during its release cycle.
Than
the reason we're doing the preview this time around is cause I'm doing
release management, and there could be little quirks that I screw up on,
so we wont announce it until we got those quirks hashed out. I think we
are looking pretty good right now
Filip
Erik Bertelsen wrote:
2006/9/2, Fili
Ok, wanted to check with you guys first, do you want a stable vote, or
release it as a beta first (ala what mark did to TC4)?
Filip
Filip Hanik - Dev Lists wrote:
the reason we're doing the preview this time around is cause I'm doing
release management, and there could be little quirks that
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 418328a412 Refactor to enforce 1-2-1 mapping between
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 31e02d0062 Refactor to enforce 1-2-1 mapping for
Noted, thanks for the feedback!
--David
On 15/06/2022 12:32, Martin Grigorov wrote:
Hi David,
Apache Tomcat's build and tests pass successfully with
JDK 19-ea+26-2060 and 20-ea+1-3 on Linux x86_64 and aarch64!
Regards,
Martin
On Tue, Jun 14, 2022 at 11:00 AM Martin Grigorov
https://issues.apache.org/bugzilla/show_bug.cgi?id=51813
--- Comment #1 from Mike Jakubik
2011-09-16 18:50:26 UTC ---
This appears to be a problem with the new jpeg encoder code in OpenJDKs
javax.imageio. We have changed our code to render a PNG instead, and the issue
appears to be solved
https://issues.apache.org/bugzilla/show_bug.cgi?id=51813
--- Comment #2 from Christopher Schultz
2011-09-16 20:51:10 UTC ---
There was a recent discussion on the users list where someone discovered that
one of the JRE imaging APIs was keeping a reference to an OutputStream and
randonly flushing
https://issues.apache.org/bugzilla/show_bug.cgi?id=51813
--- Comment #3 from Mike Jakubik
2011-09-20 16:08:58 UTC ---
Hi Christopher,
Thanks for the info, but it appears that simply switching to render a png
instead of a jpeg has fixed our problem. Unfortunately i am not a programmer
myself, an
https://issues.apache.org/bugzilla/show_bug.cgi?id=51813
Bug #: 51813
Summary: Tomcat randomly crashes with
[libtcnative-1.so.1+0x152ca]
Java_org_apache_tomcat_jni_Socket_sendbb+0x5a
Product: Tomcat Native
All,
I started to work on cleaning up the DBCP generics warnings in 7.0.x
before I remembered what "fun" it was when I did this for DBCP2. While
some of it is straight-forward, some of it requires some refactoring.
From memory, the refactoring did fix a few bugs along the way.
Given that the
https://bz.apache.org/bugzilla/show_bug.cgi?id=65340
Bug ID: 65340
Summary: Hpack decode NegativeArraySizeException: -1
Product: Tomcat 9
Version: 9.0.45
Hardware: PC
OS: Mac OS X 10.1
Status: NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=66236
--- Comment #1 from Mark Thomas ---
A code inspection suggests that this hasn't been working in previous versions.
While the special values of 0 and -1 work for FORM auth and HTTP upgrade, they
do not work for TLS renegotiation.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66236
--- Comment #2 from Mark Thomas ---
It looks like reverting to using ByteChunk to store the request body in
BufferedInputFilter should fix this. Initial impressions are that this works
but I want to run more tests before committing.
--
You ar
https://bz.apache.org/bugzilla/show_bug.cgi?id=66236
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Ducky wrote:
> Hello,
>
> I just noticed those following messages in my apache log files, and
> wasn't able to find the cause. Any documentations/insights for those
> error messages?
You are more likely to get a useful response on the users list.
http://tomcat.apache.org/lists.html
Mark
-
HI Michael,
we have add some Imdicators at the coming mod_jk 1.2.28 release.
===
JkLocalNameIndicator
Name of the Apache environment variable which can be used to
overwrite the forwarded local name. Use this only if you need to
adjust the data (see the proxy documentation).
The default va
On 21.03.2009 00:10, Michael B Allen wrote:
Hi All,
What is the status of this issue?
https://issues.apache.org/bugzilla/show_bug.cgi?id=41263
I am interested in this because NTLMSSP authentication is basically
not possible unless the remote port is accessible and I want people to
be able t
Rainer Jung wrote:
I added a comment with a non spec compliant workaround to BZ41263.
We'll seee, whether we can make the AJP Tomcat connectors "hack aware",
i.e. allow them to get the remotePort from the REMOTE_PORT env var when
set.
Only if you make sure that the REMOTE_PORT is always m
On 21.03.2009 13:23, Mladen Turk wrote:
Rainer Jung wrote:
I added a comment with a non spec compliant workaround to BZ41263.
We'll seee, whether we can make the AJP Tomcat connectors "hack
aware", i.e. allow them to get the remotePort from the REMOTE_PORT env
var when set.
Only if you make
Rainer Jung wrote:
On 21.03.2009 13:23, Mladen Turk wrote:
Rainer Jung wrote:
I added a comment with a non spec compliant workaround to BZ41263.
We'll seee, whether we can make the AJP Tomcat connectors "hack
aware", i.e. allow them to get the remotePort from the REMOTE_PORT env
var when set.
On 21.03.2009 14:12, Mladen Turk wrote:
I should read the entire logic before posting.
I missed it's an env var.
Sorry for the noise ;)
No problem at all. Better safe than sorry.
I just committed a change to TC trunk and backport proposals to pick up
the REMOTE_PORT env var for request.getRe
On Sat, Mar 21, 2009 at 9:27 AM, Rainer Jung wrote:
> On 21.03.2009 14:12, Mladen Turk wrote:
>>
>> I should read the entire logic before posting.
>> I missed it's an env var.
>>
>> Sorry for the noise ;)
>
> No problem at all. Better safe than sorry.
>
> I just committed a change to TC trunk and
On 21.03.2009 20:09, Michael B Allen wrote:
On Sat, Mar 21, 2009 at 9:27 AM, Rainer Jung wrote:
On 21.03.2009 14:12, Mladen Turk wrote:
I should read the entire logic before posting.
I missed it's an env var.
Sorry for the noise ;)
No problem at all. Better safe than sorry.
I just committed
Rainer Jung wrote:
On 21.03.2009 14:12, Mladen Turk wrote:
I should read the entire logic before posting.
I missed it's an env var.
Sorry for the noise ;)
No problem at all. Better safe than sorry.
I just committed a change to TC trunk and backport proposals to pick up
the REMOTE_PORT env v
Hi Mladen,
On 22.03.2009 10:19, Mladen Turk wrote:
Rainer Jung wrote:
On 21.03.2009 14:12, Mladen Turk wrote:
I just committed a change to TC trunk and backport proposals to pick
up the REMOTE_PORT env var for request.getRemotePort().
So we might think about forwarding REMOTE_PORT by default i
https://issues.apache.org/bugzilla/show_bug.cgi?id=50030
Summary: 1
Product: Tomcat Connectors
Version: 1.2.30
Platform: PC
Status: NEW
Severity: normal
Priority: P2
Component: JK2
AssignedTo: dev
:
https://svn.apache.org/repos/asf/tomcat/taglibs/taglibs-parent/tags/taglibs-parent-1/
The proposed v1 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as v1 Stable
Cheers
Jeremy
+1 votes from olamy, mturk and kkolinko; no -1's
Issues raised during the vote:
* duplicate LICENSE and NOTICE files, and how to avoid this
* site contents
* version of commons-skin used for site
to be addressed before we release any of the taglibs
Thanks. I'll promote the staging
nfiguration page, which currently shows the DBCP 2 configuration which
will not work on DBCP 1. That means we have a sync problem with the
Tomcat 6 and 7 documentation.
I was unable to find the configuration page for the "old" DBCP version
on the DBCP site, otherwise I would have upda
1 - 100 of 1325 matches
Mail list logo
