RE: jstl jar location

[George Stanchev]

Apologies. I accidently sent this to the wrong mailing list. Will resend to the 
user mailing list.


From: George Stanchev
Sent: Tuesday, October 20, 2020 1:02 PM
To: Tomcat Developers List 
Subject: jstl jar location

I am hoping someone can shed some lights on a question. I did try to search 
online and SO but haven't had luck in figure it out so hopefully it is a quick 
answer from the people that know that stuff. We have an uber-lib folder where 
we keep shared libraries in our TC85-hosted app. If we put jstl-1.2.jar into 
that directory but not in the application /WEB-INF/lib directory, TC generates 
[1]. If I move jstl into the application lib folder, it works. I made sure jstl 
is excluded from jarsToSkip and included in jarsToScan.

Is there any rule or switch that says that the JSP compiler cannot use the 
parent CL to resolve the jstl URIs?

George



[1]
Type Exception Report
Message The absolute uri: [http://java.sun.com/jsp/jstl/core] cannot be 
resolved in either web.xml or the jar files deployed with this application
Description The server encountered an unexpected condition that prevented it 
from fulfilling the request.
Exception
org.apache.jasper.JasperException: The absolute uri: 
[http://java.sun.com/jsp/jstl/core] cannot be resolved in either web.xml or the 
jar files deployed with this application
 
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)

org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:293)

org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:80)
org.apache.jasper.compiler.TagLibraryInfoImpl.generateTldResourcePath(TagLibraryInfoImpl.java:251)

org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:122)
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:431)
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:489)
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1445)
org.apache.jasper.compiler.Parser.parse(Parser.java:144)

org.apache.jasper.compiler.ParserController.doParse(ParserController.java:244)

org.apache.jasper.compiler.ParserController.parse(ParserController.java:105)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:203)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:375)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:351)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:335)

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:597)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:168)

org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:304)

org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1286)
org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1041)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:984)
  
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)

org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:861)

jstl jar location

[George Stanchev]

I am hoping someone can shed some lights on a question. I did try to search 
online and SO but haven't had luck in figure it out so hopefully it is a quick 
answer from the people that know that stuff. We have an uber-lib folder where 
we keep shared libraries in our TC85-hosted app. If we put jstl-1.2.jar into 
that directory but not in the application /WEB-INF/lib directory, TC generates 
[1]. If I move jstl into the application lib folder, it works. I made sure jstl 
is excluded from jarsToSkip and included in jarsToScan.

Is there any rule or switch that says that the JSP compiler cannot use the 
parent CL to resolve the jstl URIs?

George



[1]
Type Exception Report
Message The absolute uri: [http://java.sun.com/jsp/jstl/core] cannot be 
resolved in either web.xml or the jar files deployed with this application
Description The server encountered an unexpected condition that prevented it 
from fulfilling the request.
Exception
org.apache.jasper.JasperException: The absolute uri: 
[http://java.sun.com/jsp/jstl/core] cannot be resolved in either web.xml or the 
jar files deployed with this application
 
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)

org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:293)

org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:80)
org.apache.jasper.compiler.TagLibraryInfoImpl.generateTldResourcePath(TagLibraryInfoImpl.java:251)

org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:122)
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:431)
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:489)
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1445)
org.apache.jasper.compiler.Parser.parse(Parser.java:144)

org.apache.jasper.compiler.ParserController.doParse(ParserController.java:244)

org.apache.jasper.compiler.ParserController.parse(ParserController.java:105)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:203)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:375)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:351)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:335)

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:597)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:168)

org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:304)

org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1286)
org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1041)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:984)
  
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)

org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:861)

RE: [VOTE] Release Apache Tomcat 8.5.57

[George Stanchev]

Thanks Martin, it is not a stopper, just pointed it out…

From: Martin Grigorov 
Sent: Thursday, July 02, 2020 4:00 AM
To: Tomcat Developers List 
Subject: Re: [VOTE] Release Apache Tomcat 8.5.57


On Wed, Jul 1, 2020, 23:48 George Stanchev 
mailto:george.stanc...@microfocus.com>> wrote:
I ran ant ide-eclipse and the generated project contains a reference to



But D:\work\My Projects\java\Tomcat\8.5.57-src\libraries-download\cglib-3.3.0 
contains only cglib-nodep-3.3.0.jar not cglib-nodep-2.2.2.jar. Not sure if I 
did something wrong…The resulting eclipse project of course complains from 
unsatisfied dependencies…

Sorry for the trouble!
I've just fixed it!
You'll have to replace 2.2.2 with 3.3.0 in 
res/ide-support/eclipse/eclipse.classpath and re-run "ant ide-eclipse".

Regards,
Martin


George

From: Coty Sutherland mailto:csuth...@apache.org>>
Sent: Wednesday, July 01, 2020 1:48 PM
To: Tomcat Developers List mailto:dev@tomcat.apache.org>>
Subject: Re: [VOTE] Release Apache Tomcat 8.5.57

On Tue, Jun 30, 2020 at 6:14 PM Mark Thomas 
mailto:ma...@apache.org>> wrote:
The proposed Apache Tomcat 8.5.57 release is now available for voting.

The notable changes compared to the 8.5.56 release are:

- Implement a significant portion of the TLS environment variables
  for the rewrite valve.

- Reduce memory footprint of closed HTTP/2 streams

- Improve parsing of RFC 2109 cookies

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.57/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1274/

The tag is:
https://github.com/apache/tomcat/tree/8.5.57
9c649984ef92c2534a734c6584220a9a0c0c3462

The proposed 8.5.57 release is:
[ ] Broken - do not release
[x] Stable - go ahead and release as 8.5.57

+1


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

RE: [VOTE] Release Apache Tomcat 8.5.57

[George Stanchev]

I ran ant ide-eclipse and the generated project contains a reference to



But D:\work\My Projects\java\Tomcat\8.5.57-src\libraries-download\cglib-3.3.0 
contains only cglib-nodep-3.3.0.jar not cglib-nodep-2.2.2.jar. Not sure if I 
did something wrong…The resulting eclipse project of course complains from 
unsatisfied dependencies…

George

From: Coty Sutherland 
Sent: Wednesday, July 01, 2020 1:48 PM
To: Tomcat Developers List 
Subject: Re: [VOTE] Release Apache Tomcat 8.5.57

On Tue, Jun 30, 2020 at 6:14 PM Mark Thomas 
mailto:ma...@apache.org>> wrote:
The proposed Apache Tomcat 8.5.57 release is now available for voting.

The notable changes compared to the 8.5.56 release are:

- Implement a significant portion of the TLS environment variables
  for the rewrite valve.

- Reduce memory footprint of closed HTTP/2 streams

- Improve parsing of RFC 2109 cookies

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.57/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1274/

The tag is:
https://github.com/apache/tomcat/tree/8.5.57
9c649984ef92c2534a734c6584220a9a0c0c3462

The proposed 8.5.57 release is:
[ ] Broken - do not release
[x] Stable - go ahead and release as 8.5.57

+1


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

RE: Malicious Headers

[George Stanchev]

I find it quite surprising that you are worried about security for a version 
that is so old (latest Tomcat on the 7.0.x branch is 7.0.103). Proper security 
practices call for using latest versions where security issues might be 
resolved.

From: Victor Rodriguez 
Sent: Friday, March 27, 2020 11:55 AM
To: dev@tomcat.apache.org
Subject: Malicious Headers

We are using Fortify, which is a static code analysis tool to find 
vulnerabilities in your code and it's saying that code might be susceptible to 
malicious header injection, such as CRLF.  However, it also says that "Many of 
today's modern application servers will prevent the injection of malicious 
characters into HTTP headers. For example, recent versions of Apache Tomcat 
will throw an IllegalArgumentException if you attempt to set a header with 
prohibited characters. If your application server prevents setting headers with 
new line characters, then your application is not vulnerable to HTTP Response 
Splitting."

Does tomcat prevent the injection of malicious characters into HTTP headers?  
We are currently using Apache Tomcat/7.0.53.  Thanks!

--
Sent from neither my iPhone nor my iPad.

RE: Better support for OpenJSSE?

[George Stanchev]

Since I was the one that brought up a question about OpenJSSE on the User 
Mailing List several weeks ago, just wanted to bring up to your attention that 
there are quirks of OpenJSSE that people are discovering. I was able to get 
TC85 to run with OpenJSSE but admitting haven’t done extensive testing. For 
example this thread [1]. There are also other projects (such as OkHttp http 
client) that have ran into specificities on running with OpenJSSE.

[1] https://github.com/openjsse/openjsse/issues/10#issuecomment-533318077

(sorry for top posting, Outlook doesn’t make it easy)

From: Rémy Maucherat 
Sent: Thursday, September 19, 2019 5:02 AM
To: Tomcat Developers List 
Subject: Re: Better support for OpenJSSE?

On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas 
mailto:ma...@apache.org>> wrote:
On 19/09/2019 09:27, Rainer Jung wrote:



> I made a patch to detect ALPN support at runtime using reflection.
> Please have a look. Feedback welcome, whether we want to include that or
> whether we want to stick with the simpler approach we currently use.

Past experience suggests a lot of users will be on Java 8 for quite some
time. I think it makes sense to support this.

> Of
> course the windows for Java 8 plus OpenJSSE is getting smaller over
> time, and users could also use tcnative to get TLS 1.3 and HTTP/2. On
> the other hand integration of OpenJSSE is pretty simple and some users
> don't like native code in their JVM (and its maintenance). IMHO support
> for OpenJSSE (including HTTP/2) would be a nice addition.
>
> My TC 9 patch is available under:
>
> http://home.apache.org/~rjung/patches/tc9-openjsse.patch
>
> It moves the ALPN detection from classes Jre(9)Compat to class TLS in
> the same package and uses the same approach that we use for other
> runtime detection. It needs to make one method accessible, because under
> Java 9+ the implementation class SSLEngineImpl is no longer a public
> class. Since it is accessed normally via SSLEngine, direct method calls
> still work, but reflective calls no longer.

Currently TLS.java is only used by the unit tests.

We only need to use reflection on Java 8 since we know ALPN is available
on Java 9 onwards.

The module system adds additional restrictions to calling
setAccessible() that might cause problems in the future.

I was a bit worried about that too.


I wonder if a cleaner solution might be:

- Move isTlsv13Available to TesterSupport and deprecate TLS.java

- Add isAlpnAvailable() to JreCompat where:
  - Java 7 (for 8.5.x) hard codes to false
  - Java 8 uses reflection
  - Java 9 hard codes to true

+1

Personally I wouldn't use OpenJSSE over tomcat-native (performance ? long term 
support ?), but since it's only about making the Tomcat code a bit more 
flexible that works for me.

Rémy

RE: TLSv1.3 and 9.0.next

[George Stanchev]

Mark,

Can you elaborate around the following:


All combinations support server initiated requests for client certificates 
apart from NIO[2]+JSSE on Java 11 as the Java 11 TLSv1.3 implementation does 
not include post handshake authentication.


What are the use cases affected. Is it for TLS upgrade when a certain resource 
is being requested? 

Thanks in advance,
George

-Original Message-
From: Mark Thomas  
Sent: Thursday, October 11, 2018 2:39 PM
To: Tomcat Developers List 
Subject: TLSv1.3 and 9.0.next

Hi,

As you probably noticed I've been working on TLS 1.3 support, building on 
Chris's work in BZ 62748.

The current status is the Tomcat Native 1.2.x and Tomcat 9.0.x support
TLSv1.3 in any of the following combinations:
- NIO[2]+JSSE on Java 11
- NIO[2]+OpenSSL on Java 8 onwards
- APR/Native on Java 8 onwards

All combinations support server initiated requests for client certificates 
apart from NIO[2]+JSSE on Java 11 as the Java 11 TLSv1.3 implementation does 
not include post handshake authentication.

I have made quite a few changes to the Native code to support this.

My plan going forwards is as follows:

- give folks until early next week to review the native changes
- tag 1.2.18 early next week
- hopefully release 1.2.18 late next week
- update 9.0.x to require 1.2.18 or later
- tag / release 9.0.x

Alongside the above, I'll be backporting the TLSv1.3 support to 8.5.x and 9.0.x.

Thoughts, comments and especially code reviews welcome.

Mark

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

small tiny issue with TC 8.5 ant "clean" target

[George Stanchev]

The "clean" target of the TC build file leaves "output\jdbc-pool" directory. 
This is because the "clean" target first deletes the output dir [1] but then 
calls the jdbc "clean" script [2] which recreates the directory in the "output" 
location [3]. Why would [3] be called as part of a "clean" script?

Since this is really a small issue, do you want BZ issue submitted or someone 
can address it as a regular cleanup.


[1] 
http://svn.apache.org/viewvc/tomcat/tc8.5.x/trunk/build.xml?view=markup#l2582
[2] 
http://svn.apache.org/viewvc/tomcat/tc8.5.x/trunk/build.xml?view=markup#l2587
[3] 
http://svn.apache.org/viewvc/tomcat/tc8.5.x/trunk/modules/jdbc-pool/build.xml?view=markup#l215

RE: Test keys and certs

[George Stanchev]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Tuesday, August 08, 2017 5:23 AM
To: Tomcat Developers List 
Subject: Test keys and certs

All,

Just a heads up.

A few days ago I started to look at bug 59423. I saw all sorts of errors when I 
tried to configure a clean Tomcat build for CLIENT-CERT.

As I dug into the errors it appeared that Tomcat wasn't handling an unexpected 
connection close during the renegotiation. I have a patch for this that I'll 
commit once I have completed some more testing.

I also spent a long time trying to figure out why CLIENT-CERT was failing 
unexpectedly in some cases. The short answer is that it fails in Chrome but not 
with FireFox nor with openssl s_client.

The failure in Chrome occurs when it tries to find a matching user cert for the 
provided trusted certs. For some reason Chrome can't match our current user 
test cert with the CA. My guess is that expects/requires more fields to be 
populated than just C and CN.

I've been experimenting with a new CA created from scratch that populates more 
of the fields and this does work with Chrome.

Therefore, I plan to replace our current test CA with the new one I have 
created and, therefore, also replace all the test keys and certs used in the 
unit tests. I'll also update the notes for creating these files and the 
openssl.cnf with a few more defaults.

I might even get around to looking at 59423 ;)

Mark

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=59423

-



Is it possible the recent changes [1] has affected it? Chrome no longer looks 
in CN, which is ignored but rather expects SAN to be filled up. Perhaps 
Tomcat's test certs lack SAN?

[1] https://www.thesslstore.com/blog/security-changes-in-chrome-58/


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

RE: [VOTE] Release Apache Tomcat 8.5.18

[George Stanchev]

Mark,

Can you look at my comments at the user's mailing list on the original thread 
about the encoding issue. The issue seems to have resurfaced in a different 
form.

George

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

warning message - small issue

[George Stanchev]

Hello,

Let me know if you want an official bug report or this not will suffice. The 
message "jsseUtil.noVerificationDepth" which is defined in

https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/net/jsse/LocalStrings.properties

as a one arg string:

jsseUtil.noVerificationDepth=The truststoreProvider [{0}] does not support the 
certificateVerificationDepth configuration option

But the argument is never used when emitting the message. Its only usage is in

java\org\apache\tomcat\util\net\jsse\JSSEUtil.java

as follows: log.warn(sm.getString("jsseUtil.noVerificationDepth"));

I can submit a bug report or any of the devs can just fix the string (or, 
preferably the warning)

George

RE: JK 1.2.41

[George Stanchev]

Thanks for your reply Mark. I know how OSS projects work. I was just hoping 
that this issue, being rather small in fix-scope and large in impact-scope 
would be picked up for the next release. I know also that  you're not the 
person usually maintaining the Connectors so I appreciate the new release (with 
or without our issue).

Please let me know if I can help in any way with our particular issue to get it 
in the upcoming releases...

Best Regards,
George



-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Monday, July 27, 2015 2:44 AM
To: Tomcat Developers List
Subject: Re: JK 1.2.41

On 27/07/2015 00:05, George Stanchev wrote:
 Is there anyone working on connectors or Apache is doing just 
 emergency security releases?

As with all ASF projects, committers work on projects when they want to and 
when they have time to.

At the moment, I'm working on a 1.2.41 release (as you can see from the dev 
list activity over the last 24 hours).

svn log shows what activity there has been (nothing since March until I 
started the 1.2.41 release).

 I've submitted a bug [1] with a simple, one liner fix that got 
 overlooked for this release. We're maintaining a parallel source 
 branch to get around this issue which breaks authentication 
 integrations and I was hoping to get it in the .41 release given the 
 fact that connectors are released once in a blue moon.

It isn't going to get into 1.2.41 now it has been tagged and the release vote 
has started but I'll take a look for the next release. Keep in mind my C skills 
are basic to say the least so I might have to pass on this if I can't convince 
myself that the patch is OK.

 Is there anything else I can do besides point to a problem and attach 
 a patch with the solution to get it in a release? Are Connectors 
 orphaned?

Do that several times, become a committer and you can do the release yourself 
:).

Mark

 George
 
 [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=57836

-
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

JK 1.2.41

[George Stanchev]

Is there anyone working on connectors or Apache is doing just emergency 
security releases?

I've submitted a bug [1] with a simple, one liner fix that got overlooked for 
this release. We're maintaining a parallel source branch to get around this 
issue which breaks authentication integrations and I was hoping to get it in 
the .41 release given the fact that connectors are released once in a blue 
moon. 

Is there anything else I can do besides point to a problem and attach a patch 
with the solution to get it in a release? Are Connectors orphaned?

George


[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=57836


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

Issue with a principal and remote_user

[George Stanchev]

I am facing an issue with authentication. Please forgive me if I am posting 
this in the wrong place.

I am running IIS+jk_connect+Tomcat 7.0.59 but this issue was replicated on 
Tomcat 5.5.36. We are using a security filter from a 3rd party that is failing 
to engage while requests are sent over AJP via jk_connect. I was able to trace 
the issue to the 3rd party checking for previously authenticated principal via 
HttpServletRequest.getUserPrincipal(). Regular call via HTTP connector returns 
null. Call over jk_connect returns CoyotePrinciapal object but the getName() on 
it is . The whole issue starts in the jk_isapi_plugin.c where

GET_SERVER_VARIABLE_VALUE(REMOTE_USER, s-remote_user);

This macro is defined as

#define GET_SERVER_VARIABLE_VALUE(name, place)  \
  do {  \
(place) = dup_server_value(private_data-lpEcb, \
   (name),  \
   private_data-p);   \
  } while(0)

dup_server_value is

static char *dup_server_value(LPEXTENSION_CONTROL_BLOCK lpEcb,
  const char *name, jk_pool_t *p)
{DWORD sz = HDR_BUFFER_SIZE;
char buf[HDR_BUFFER_SIZE];
char *dp;

if (lpEcb-GetServerVariable(lpEcb-ConnID, (LPSTR)name, buf, sz))
return jk_pool_strdup(p, buf);

and jk_pool_strdup starts as

char *jk_pool_strdup(jk_pool_t *p, const char *s)
{
char *rc = NULL;
   if (s  p) {
size_t size = strlen(s);

if (!size) {
return ;
}

So essentially GetServerVariable(REMOTE_USER, buf, sz) returns TRUE and sets 
buf[0]=0 and sz to 0 indicating no REMOTE_USER is present. However, this is 
converted to  by jk_pool_strdup and sent over AJP to Tomcat as a remote_user 
with size of 0 bytes.


Since a remote_user field IS sent to Tomcat, it creates a CoyotePrincipal 
object with a principal name of empty string.

There is a problem somewhere: two requests over two connectors generate two 
different principal objects (null and empty CoyotePrincipal). If I'd to put a 
finger, I would say the issue is with the IIS connector converting empty 
REMOTE_USER value to  instead of NULL.

Can someone with knowledge confirm? I'd like to raise an issue but I want to 
submit it into the correct component.

George