https://bz.apache.org/bugzilla/show_bug.cgi?id=68677
--- Comment #5 from dub...@gmail.com ---
Again - I need something integrated w/ Tomcat and a true reverse proxy over
HTTP will never be that. How would things like REMOTE_USER or the client
certificate get propagated to Tomcat
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677
--- Comment #4 from Christopher Schultz ---
The typical way to do this is:
1. Remove all inbound HTTP headers you want to set at the proxy
2. Set your specific HTTP headers at the proxy
3. Read your now-trusted HTTP headers from the request
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677
--- Comment #3 from dub...@gmail.com ---
I'm not entirely sure, but the point here is that I dont want to use on HTTP
headers. The current ISAPI filter already passes on those. The problem is
that they can be spoofed by the client so I'm
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677
--- Comment #2 from Christopher Schultz ---
Does IIS have the ability to add request headers to proxied requests? For
example, if you were using client -> [HTTP] -> IIS -> [HTTP] -> Tomcat, would
you be able to set arbitrary
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677
dub...@gmail.com changed:
What|Removed |Added
OS||All
--- Comment #1 from dub
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677
Bug ID: 68677
Summary: no support for enviroment variables/request attributes
Product: Tomcat Connectors
Version: 1.2.49
Hardware: PC
Status: NEW
Severity: normal
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
https://bz.apache.org/bugzilla/show_bug.cgi?id=68663
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://bz.apache.org/bugzilla/show_bug.cgi?id=68663
--- Comment #1 from Mark Thomas ---
*** Bug 68664 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=68664
Mark Thomas changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=68664
Mustafa Bozdemir changed:
What|Removed |Added
CC||mustafa.bozdemir@fisglobal
https://bz.apache.org/bugzilla/show_bug.cgi?id=68664
Bug ID: 68664
Summary: CVE-2024-22029 Incorrect default permissions
vulnerability
Product: Tomcat 9
Version: 9.0.86
Hardware: All
OS: All
https://bz.apache.org/bugzilla/show_bug.cgi?id=68663
Bug ID: 68663
Summary: CVE-2024-22029 Incorrect default permissions
vulnerability
Product: Tomcat 9
Version: 9.0.86
Hardware: All
OS: All
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
https://bz.apache.org/bugzilla/show_bug.cgi?id=68631
--- Comment #3 from Mark Thomas ---
Update to latest 9.0.x release and retest.
If you still see the issue, provide the simplest possible test case (with
source) that demonstrates the issue on a clean install of Tomcat.
Not marking
https://bz.apache.org/bugzilla/show_bug.cgi?id=68631
--- Comment #2 from Suryanarayana Garlapati
---
Any help here?
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev
https://bz.apache.org/bugzilla/show_bug.cgi?id=68634
--- Comment #1 from OKUYAMA Atsushi ---
Created attachment 39591
--> https://bz.apache.org/bugzilla/attachment.cgi?id=39591=edit
server.xml for reproducing.
--
You are receiving this mail because:
You are the assignee for the
https://bz.apache.org/bugzilla/show_bug.cgi?id=68634
Bug ID: 68634
Summary: Forwards using custom response classes do not wait for
session replication
Product: Tomcat 9
Version: 9.0.85
Hardware: Other
OS
https://bz.apache.org/bugzilla/show_bug.cgi?id=68631
--- Comment #1 from Suryanarayana Garlapati
---
This was working earlier in 9.0.20 and now we had upgraded to 9.0.74 and
observing the issue.
--
You are receiving this mail because:
You are the assignee for the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=68631
Suryanarayana Garlapati changed:
What|Removed |Added
Severity|critical|blocker
Priority
https://bz.apache.org/bugzilla/show_bug.cgi?id=68631
Bug ID: 68631
Summary: Observing
org.apache.catalina.connector.ClientAbortException:
java.net.SocketTimeoutException
Product: Tomcat 9
Version: 9.0.74
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
Mark Thomas changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
Naresh changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME
https://bz.apache.org/bugzilla/show_bug.cgi?id=68348
--- Comment #8 from avdl...@solcon.nl ---
(In reply to notify.bharani from comment #4)
> I tested in both tomcat 8 and 9 latest versions, but still the cookies are
> not coming as partitioned even though I have provided the below s
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
--- Comment #12 from Mark Thomas ---
And again, this works for me with a clean build of 9.0.x.
Have you install New Relic or any other additional software on the Tomcat
instance you are using to produce this issue?
--
You are receiving
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
--- Comment #11 from Naresh ---
Created attachment 39585
--> https://bz.apache.org/bugzilla/attachment.cgi?id=39585=edit
POC of the issue
mark,
It's just simple reproduce steps, kindly refer the demo video inside zip and
check o
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
Mark Thomas changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
--- Comment #9 from Mark Thomas ---
Are you using NewRelic by any chance?
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
Naresh changed:
What|Removed |Added
Status|NEEDINFO|NEW
--- Comment #8 from Naresh
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
Naresh changed:
What|Removed |Added
CC||nareshnk1...@gmail.com
--- Comment #7 from
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
Mark Thomas changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #6 from Mark
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
Naresh changed:
What|Removed |Added
Status|NEEDINFO|NEW
--- Comment #5 from Naresh
https://bz.apache.org/bugzilla/show_bug.cgi?id=68558
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=68558
John Engebretson changed:
What|Removed |Added
Status|NEEDINFO|NEW
--
You are receiving
https://bz.apache.org/bugzilla/show_bug.cgi?id=68558
--- Comment #9 from John Engebretson ---
Regarding #1: apologies, I was able to track down an invokeinterface that
confused our primary tool. Specifically, a class calling
HttpServletRequest.getMethod() on an instance
https://bz.apache.org/bugzilla/show_bug.cgi?id=68348
--- Comment #7 from Mark Thomas ---
Sorry, you're right. I thought partitioned support was going to be in the Feb
releases.
The OP needs to follow this up on the users list.
--
You are receiving this mail because:
You are the assignee
https://bz.apache.org/bugzilla/show_bug.cgi?id=68348
--- Comment #6 from Christopher Schultz ---
(In reply to Mark Thomas from comment #5)
> Look at the version numbers. The fixed versions haven't been released yet.
??
All versions mentioned in comment #3 have been released.
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=68348
Mark Thomas changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution
https://bz.apache.org/bugzilla/show_bug.cgi?id=68348
notify.bhar...@gmail.com changed:
What|Removed |Added
Resolution|FIXED |---
CC
https://bz.apache.org/bugzilla/show_bug.cgi?id=68558
Mark Thomas changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #8 from Mark
https://bz.apache.org/bugzilla/show_bug.cgi?id=68558
John Engebretson changed:
What|Removed |Added
Status|NEEDINFO|NEW
--- Comment #7 from John
https://bz.apache.org/bugzilla/show_bug.cgi?id=68558
--- Comment #6 from John Engebretson ---
Thank you for the quick turnaround! Additional data:
Referring to #1:
> getMethod() is already effectively cached due to use of
> MessageBytes.toStringType()
Our data is clear that this
https://bz.apache.org/bugzilla/show_bug.cgi?id=68558
Mark Thomas changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #5 from Mark
https://bz.apache.org/bugzilla/show_bug.cgi?id=68558
--- Comment #4 from Mark Thomas ---
A quick update:
1.
getMethod() is already effectively cached due to use of
MessageBytes.toStringType()
getQueryString() could be cached but there is a potential performance issue. If
applications parse
https://bz.apache.org/bugzilla/show_bug.cgi?id=68558
--- Comment #3 from Mark Thomas ---
Thanks for the additional info. I'll try and address each part in turn.
1. Caching the key fields is low cost as it is just a reference to an existing
String. I think that is a better solution that trying
https://bz.apache.org/bugzilla/show_bug.cgi?id=68089
--- Comment #12 from John Engebretson ---
String compaction made charAt() more expensive, thanks to checks on format and
range. String.length() remains an integer check.
That said, charAt() isn't that bad, so it's an option if functionally
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
--- Comment #4 from Christopher Schultz ---
(In reply to Naresh from comment #2)
> Take for example before login request URI is "/bill/login" with request body
> of "leacsrf=c8b01130-3e28-4f29-b9e6-f9f54f3f2501"
https://bz.apache.org/bugzilla/show_bug.cgi?id=68089
--- Comment #11 from Christopher Schultz ---
(In reply to Mark Thomas from comment #9)
> I did look at using !startsWith("jakarta") but that is ~2x slower than a
> length check.
>
> I've coded up the length check an
https://bz.apache.org/bugzilla/show_bug.cgi?id=68089
Mark Thomas changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596
--- Comment #9 from John Engebretson ---
Responding to these sections of comment #6:
> The setPropertyResolved(boolean) method is not overwritten in subclasses.
> This is a common situation that occurs everywhere, thus I wond
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596
--- Comment #8 from Mark Thomas ---
I've been looking at this some more.
The relevant methods on ELResolver are:
getValue()
getType()
setValue()
isReadOnly()
convertToType()
invoke()
At the start of each of those methods
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596
--- Comment #7 from Mark Thomas ---
Thanks for the additional review Konstantin.
ELResolver.convertToType() is public API. It is defined by the specification
and we can't change that.
Your comment about setting setPropertyResolved(false
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596
--- Comment #6 from Konstantin Kolinko ---
(In reply to John Engebretson from comment #0)
> context.setPropertyResolved(false);
> ...
>
> context can be of type ELContextImpl, ELContextWrapper, Evalu
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596
--- Comment #5 from John Engebretson ---
Yep. Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596
Mark Thomas changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #4 from Mark
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
Mark Thomas changed:
What|Removed |Added
Status|REOPENED|NEEDINFO
--- Comment #3 from Mark
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
Naresh changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
https://bz.apache.org/bugzilla/show_bug.cgi?id=68593
--- Comment #3 from Mark Thomas ---
*** Bug 68603 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
Mark Thomas changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=68603
Bug ID: 68603
Summary: Request Context path and Query param gets replaced
Product: Tomcat 9
Version: 9.0.83
Hardware: PC
Status: NEW
Severity: major
Priority
https://bz.apache.org/bugzilla/show_bug.cgi?id=68089
--- Comment #9 from Mark Thomas ---
I did look at using !startsWith("jakarta") but that is ~2x slower than a length
check.
I've coded up the length check and am just running some tests locally.
--
You are receiving this mail be
https://bz.apache.org/bugzilla/show_bug.cgi?id=68559
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=68572
--- Comment #2 from Mark Thomas ---
*** Bug 68599 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=68599
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://bz.apache.org/bugzilla/show_bug.cgi?id=68599
Bug ID: 68599
Summary: migration tool jakartaee-migration-1.0.7 does not
convert xmlrpc-server-3.1.3.jar
Product: Tomcat 10
Version: 10.1.18
Hardware: PC
https://bz.apache.org/bugzilla/show_bug.cgi?id=68597
Bug ID: 68597
Summary: hannover messe
Product: Tomcat Connectors
Version: unspecified
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596
--- Comment #3 from John Engebretson ---
> This needs some more thought...
Thanks, I'll keep chewing on it too.
> Note: This may get moved to an enhancement if there isn't an obvious way to
> improve this)
Makes sense, thanks.
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596
--- Comment #2 from Mark Thomas ---
#1 isn't an option unfortunately. With more complex EL expressions
ELContext.isPropertyResolved() will return true at the start of the call to
convertToType(). At least one test fails if this code is removed
https://bz.apache.org/bugzilla/show_bug.cgi?id=68089
--- Comment #8 from John Engebretson ---
Created attachment 39575
--> https://bz.apache.org/bugzilla/attachment.cgi?id=39575=edit
Support class for the speed test
--
You are receiving this mail because:
You are the assignee for the
https://bz.apache.org/bugzilla/show_bug.cgi?id=68089
--- Comment #7 from John Engebretson ---
Created attachment 39574
--> https://bz.apache.org/bugzilla/attachment.cgi?id=39574=edit
Speed test
--
You are receiving this mail because:
You are the assignee for the
https://bz.apache.org/bugzilla/show_bug.cgi?id=68089
John Engebretson changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bz.apache.org/bugzilla/show_bug.cgi?id=68119
--- Comment #3 from John Engebretson ---
This optimization was effective in production and reduced the method cost by
approximately 2/3rds, saving more than 0.5% of cpu.
The remaining time comes from another invokevirtual in the method which
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596
--- Comment #1 from John Engebretson ---
Created attachment 39573
--> https://bz.apache.org/bugzilla/attachment.cgi?id=39573=edit
Support class for the speed test
--
You are receiving this mail because:
You are the assignee for the
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596
Bug ID: 68596
Summary: Remaining overhead in
javax.el.CompositeELResolver.convertToType
Product: Tomcat 9
Version: 9.0.85
Hardware: All
OS: All
https://bz.apache.org/bugzilla/show_bug.cgi?id=68068
--- Comment #5 from John Engebretson ---
Production results confirm a small improvement - greater than zero but not
enormous. Sorry, I'm not able to provide hard numbers because of the huge
number of distinct code paths.
--
You
https://bz.apache.org/bugzilla/show_bug.cgi?id=68559
--- Comment #8 from Mark Thomas ---
I've been able to look at this some more. Thanks so much for the test case. It
really speeds up the process.
The processing paths for sync and async are distinct. Currently the error
handling in async
https://bz.apache.org/bugzilla/show_bug.cgi?id=68449
Mark Thomas changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=68593
Mark Thomas changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution
https://bz.apache.org/bugzilla/show_bug.cgi?id=68593
Christopher Schultz changed:
What|Removed |Added
Status|NEW |NEEDINFO
OS
https://bz.apache.org/bugzilla/show_bug.cgi?id=68558
--- Comment #2 from John Engebretson ---
> Are you sure about the request parameters being parsed multiple times? They
> should only be parsed once per request.
Yes - this appears to be triggered when an extra param is added by a JSP
i
https://bz.apache.org/bugzilla/show_bug.cgi?id=68593
Bug ID: 68593
Summary: Request Context is replaced after restoreRequest()
Product: Tomcat 9
Version: 9.0.83
Hardware: PC
Status: NEW
Severity: major
Priority
301 - 400 of 47005 matches
Mail list logo
