date:20220526

Re: Upgrade tomcat 7 to 10.

2022-05-26 Thread Jason Wee

As what Christopher Schultz mentioned, "including switching package
names", i.e. from javax to jakarta.. when I did the webapp migration
to tomcat 10, I had to make all the libraries to reference jakarta
though, including taglib-mailer, jsp  and so on.

hth

Jason

On Fri, May 27, 2022 at 8:53 AM Rodrigo Cunha  wrote:
>
> >
> > I suspect you should be able to upgrade your Tomcat from 7 to 10 in one
> > shot, but you might want to go from 7->9 and wait a little on 10.
> >
> Yes, it is! but not in a production environment. I want to upgrade in only
> one shot.
>
> On Thu, May 26, 2022 at 8:32 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Rodrigo,
> >
> > On 5/26/22 17:16, Rodrigo Cunha wrote:
> > > i need upgrade my tomcat server from 7 to 10. I don't saw in internet
> > > nothing about that. Commonly i upgraded in steps, 7 to 8, 8 to 9 and 9 to
> > > 10.
> > > Are there a problem upgrade from 7 to 10?
> >
> > I suspect you should be able to upgrade your Tomcat from 7 to 10 in one
> > shot, but you might want to go from 7->9 and wait a little on 10.
> >
> > Why?
> >
> > Tomcat 10 is significantly different because it implements a new version
> > of the servlet and related specifications, including switching package
> > names, etc. There *is* an automated conversion tool that can be used at
> > deployment-time to convert your pre-Jakarta-EE application to a
> > Jakarta-EE application, but you might not want to trust it immediately
> > in production without a whole lot of testing. So I recommend Tomcat 9 at
> > first.
> >
> > YMMV
> >
> > Something that is critically important is that, when upgrading, you
> > don't even try to re-use the existing server.xml file you have for your
> > Tomcat 7 installation. Instead, look at the differences between your
> > current server.xml file and an unmodified one from the original
> > distribution of Tomcat 7, and make some notes. Then, make similar
> > changes to the original server.xml file from the new Tomcat.
> >
> > -chris
> >
>
>
> --
> Atenciosamente,
> Rodrigo da Silva Cunha
> São Gonçalo, RJ - Brasil

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

RE: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix

2022-05-26 Thread Ralph Atallah

Hi Mark,

Thanks again for the prompt response. 

You wrote below:  "If the original request only has a Host header, then 
allowHostHeaderMismatch="false" isn't going to do anything because there is no 
mismatch.".  I am not clear on what this means.  What should the match be 
between?  I thought the comparison for the match was between the URL's 
hostname, i.e. "example.com" in the http://example.com/myapp URL, and the Host 
header value which is "attacker.com".  If that understanding is incorrect, 
please point me in the right direction of what it should be.

The AbstractHttp11Processor class does not get to the allowHostHeaderMismatch 
detection code because the uriBC (URI ByteChunk) that it reads is expecting an 
absolute URL (http://example.com/myapp), but instead, it is getting a relative 
one /myapp.  The reason I say the code expects an absolute URL is because it 
checks for and "http" string at the beginning.  This makes me wonder whether 
there is a setting that controls that URI format, absolute or relative.

Regarding the addition of a filter that you propose, we have an existing one in 
our application, but by the time it is reached, the URL that we see is already 
http://attacker.com/myapp, i.e. already "redirected".  Technically we could 
check there against a whitelist, but this would make the solution less 
out-of-the box, and more needy of user configuration in our app.  We prefer an 
out-of-the-box secure solution.

Any thoughts on the above?

Thanks,
Ralph

-Original Message-
From: Mark Thomas  
Sent: Thursday, May 26, 2022 12:21 PM
To: users@tomcat.apache.org
Subject: Re: allowHostHeaderMismatch option only works if the Host Header has 
an http or https prefix

WARNING: This email originated from outside of CallMiner. Do not click any 
links or open any attachments unless you recognize the sender and know that the 
content is safe. Please report suspicious emails to: 
reportsuspiciousema...@callminer.com 

On 26/05/2022 14:29, Ralph Atallah wrote:
> Hi Mark,
>
> What we are trying to do is to prevent Host header attacks by ensuring that 
> the host name in the http request URL always matches the "Host" header in the 
> request.  If it does not, we are supposed refuse the request and respond with 
> 400 Bad Request as per OWASP recommendations.   Here are some examples:
>
> Normal request
> GET http://example.com/myapp
> Host: example.com
> Expected response:  200 OK
>
> Request with a host header attack
> GET http://example.com/myapp
> Host: attacker.com
> Expected response:  400 Bad Request
>
> The AbstracktHttp11Processor.java class seems to be doing exactly that in the 
> code snippet below:
>
> if (allowHostHeaderMismatch) {
>   // The requirements of RFC 2616 are being
>   // applied. If the host header and the request
>   // line do not agree, the request line takes
>   // precedence
>   hostValueMB = headers.setValue("host");
>   hostValueMB.setBytes(uriB, uriBCStart + pos, slashPos - pos);
>   } else {
>// The requirements of RFC 7230 are being
>// applied. If the host header and the request
>// line do not agree, trigger a 400 response.
>badRequest("http11processor.request.inconsistentHosts");
>   }
>
> However, this portion of the code is never reached for the reason mentioned 
> in the previous email.
>
> By the time the request reaches our application, the 
> HttpServletRequest.getRequestURL() returns  http://attacker.com/myapp instead 
> of http://example.com/myapp
> We have enabled the AccessLogValve in server.xml in the hope to see the URL 
> that reaches tomcat, but it seems that we only get the relative URL there, 
> never the absolute one, i.e. we only see /myapp when we print %u for example.
>
> Any tips in this area would be much appreciated.

If the original request only has a Host header, then
allowHostHeaderMismatch="false" isn't going to do anything because there
is no mismatch.

If you want to reject requests that have a Host header that isn't one
you recognize then there are multiple options:

- write a Filter
- write a Valve
- configure a Host (or several) for the requests you want to allow and
   deploy an ROOT to the default host that rejects everything else.

Mark

> Ralph
>
> -Original Message-
> From: Mark Thomas 
> Sent: Thursday, May 26, 2022 3:24 AM
> To: users@tomcat.apache.org
> Subject: Re: allowHostHeaderMismatch option only works if the Host Header has 
> an http or https prefix
>
> WARNING: This email originated from outside of CallMiner. Do not click any 
> links or open any attachments unless you recognize the sender and know that 
> the content is safe. Please report suspicious emails to: 
> reportsuspiciousema...@callminer.com 
> 
>
> On 26/05/2022 02:20, Ralph Atallah wrote:
>> Hi,
>>
>> We use Tomcat

Re: Upgrade tomcat 7 to 10.

2022-05-26 Thread Rodrigo Cunha

>
> I suspect you should be able to upgrade your Tomcat from 7 to 10 in one
> shot, but you might want to go from 7->9 and wait a little on 10.
>
Yes, it is! but not in a production environment. I want to upgrade in only
one shot.

On Thu, May 26, 2022 at 8:32 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Rodrigo,
>
> On 5/26/22 17:16, Rodrigo Cunha wrote:
> > i need upgrade my tomcat server from 7 to 10. I don't saw in internet
> > nothing about that. Commonly i upgraded in steps, 7 to 8, 8 to 9 and 9 to
> > 10.
> > Are there a problem upgrade from 7 to 10?
>
> I suspect you should be able to upgrade your Tomcat from 7 to 10 in one
> shot, but you might want to go from 7->9 and wait a little on 10.
>
> Why?
>
> Tomcat 10 is significantly different because it implements a new version
> of the servlet and related specifications, including switching package
> names, etc. There *is* an automated conversion tool that can be used at
> deployment-time to convert your pre-Jakarta-EE application to a
> Jakarta-EE application, but you might not want to trust it immediately
> in production without a whole lot of testing. So I recommend Tomcat 9 at
> first.
>
> YMMV
>
> Something that is critically important is that, when upgrading, you
> don't even try to re-use the existing server.xml file you have for your
> Tomcat 7 installation. Instead, look at the differences between your
> current server.xml file and an unmodified one from the original
> distribution of Tomcat 7, and make some notes. Then, make similar
> changes to the original server.xml file from the new Tomcat.
>
> -chris
>


-- 
Atenciosamente,
Rodrigo da Silva Cunha
São Gonçalo, RJ - Brasil

Re: What causes "client errors" with mod_jk

2022-05-26 Thread Christopher Schultz


Rainer,

On 5/26/22 17:25, Rainer Jung wrote:

Hi Chris,

Am 26.05.2022 um 21:49 schrieb Christopher Schultz:

On 5/16/22 13:48, Christopher Schultz wrote:


I see the place in the code where the error is generated, but I'm not 
familiar enough with the code to know how to add that kind of thing. 
The function in question (ajp_process_callback) has a pointer to a 
jk_ws_service_t structure. Is it as simple as also logging like this?


   /* convert start-time to a string */
   char[32] timestamp;
   apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", 
r->r->request_time);

   /* emit a detailed log message */
   jk_log(l, JK_LOG_INFO,
  "(%s) Request to (%s %s) started at %s,%ld",
  ae->worker->name, r->method, r->req_uri, timestamp, 
r->r->request_time.tm_usec);


Does anyone think this might be generally useful?


It looks like I needed a few more things in order to get this to work:

   {
 char *timestamp = malloc(32);
 apr_time_exp_t *timerec = malloc(sizeof(apr_time_exp_t));
 apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;
 apr_time_exp_gmt(timerec, ap->r->request_time);
 apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", timerec);
 /* emit a detailed log message */
 jk_log(l, JK_LOG_INFO,
    "(%s) Request to (%s %s) started at %s",
    ae->worker->name, r->method, r->req_uri, timestamp);
 free(timerec);
 free(timestamp);
   }

The compiler wouldn't let me use an automatically-allocated char[32] 
so I had to malloc it. I also had to convert from long to 
apr_time_exp_t which required another structure/malloc as well.


Finally, I had to cast the r->ws_private to apache_private_data_t* 
which required me to copy/paste the definition of 
apache_private_data_t from mod_jk.h into jk_ajp_common.c -- just as a 
test for now.


Obviously, this works only for Apache httpd.

I have it running on one of my web servers for now -- hoping to catch 
an error and see this additional logging to see if it's helpful to me. 
(LOL just segfaulted; time to go back and look.)


What would be the best way to get the "start time" of the request in a 
platform-independent way? Maybe just expand the jk_ws_service 
structure to include it?


Apart from the info chuck send via PM, I think it would be better to try 
to add a unique request ID as a correlation ID. Apache can already 
generate them using mod_unique_id and you can add them there to the 
access log.


Would you prefer to use mod_unique_id + unique-id-logging in mod_jk over 
just adding more request-level information to the mod_jk.log? I'm kind 
of okay either way, but for my current purposes it seems more convenient 
to have all relevant information in a single place (the mod_jk.log file).



Now how could we make that ID accessible from mod_jk?

We could either add it as a new item to jk_ws_service and I think it 
would be a good fit. Any server not yet providing it, eg. if we find no 
way adding it in IIS, would have a null value there (or some constant we 
init it to). We are free to add things, because we do not really provide 
a public API used elsewhere which we need to keep stable.


When we do logging in mod_jk, we use jk_log(jk_logger_t *l, ...) where 
the remaining arguments are just standard log arguments. We could add a 
new jk_request_log(jk_logger_t *l, jk_ws_service_t *s, ...) and that 
function retrieves the request ID from s and adds it to the log line.


It seems, typically where we want to log something that would benefit 
from a request ID, we have the jk_ws_service_t at hand, so could add it 
to the log call.


WDYT?


I'm okay adding either or both of these "features" to the JK portion of 
the code. If we are considering "enhancing" this kind of logging in the 
JK portion, I would recommend that we add request_start_time to the 
jk_ws_service; I don't see a good way to determine the nature of the 
host web server from within the JK code and it's better-done from the 
outside-in rather than the inside-out.


Unrelated: I believe the segfaults I'm seeing have to do with me simply 
updating the .so file on the disk before restarting the httpd process. 
As soon as I copy the .so file over the existing module binary, I start 
getting a string of segfaults in the log file. When I don't try to 
"hot-update" the module binary, I don't see any of that happening. (I 
also don't see any possible segfaults in my code at this point, either.) 
I have httpd set up to dump cores but I think my file permissions are 
wrong so I'm not actually getting anything in there (yet).


-chris

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

Re: Upgrade tomcat 7 to 10.

2022-05-26 Thread Christopher Schultz


Rodrigo,

On 5/26/22 17:16, Rodrigo Cunha wrote:

i need upgrade my tomcat server from 7 to 10. I don't saw in internet
nothing about that. Commonly i upgraded in steps, 7 to 8, 8 to 9 and 9 to
10.
Are there a problem upgrade from 7 to 10?


I suspect you should be able to upgrade your Tomcat from 7 to 10 in one 
shot, but you might want to go from 7->9 and wait a little on 10.


Why?

Tomcat 10 is significantly different because it implements a new version 
of the servlet and related specifications, including switching package 
names, etc. There *is* an automated conversion tool that can be used at 
deployment-time to convert your pre-Jakarta-EE application to a 
Jakarta-EE application, but you might not want to trust it immediately 
in production without a whole lot of testing. So I recommend Tomcat 9 at 
first.


YMMV

Something that is critically important is that, when upgrading, you 
don't even try to re-use the existing server.xml file you have for your 
Tomcat 7 installation. Instead, look at the differences between your 
current server.xml file and an unmodified one from the original 
distribution of Tomcat 7, and make some notes. Then, make similar 
changes to the original server.xml file from the new Tomcat.


-chris

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

Re: What causes "client errors" with mod_jk

2022-05-26 Thread Rainer Jung


Hi Chris,

Am 26.05.2022 um 21:49 schrieb Christopher Schultz:

On 5/16/22 13:48, Christopher Schultz wrote:


I see the place in the code where the error is generated, but I'm not 
familiar enough with the code to know how to add that kind of thing. 
The function in question (ajp_process_callback) has a pointer to a 
jk_ws_service_t structure. Is it as simple as also logging like this?


   /* convert start-time to a string */
   char[32] timestamp;
   apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", 
r->r->request_time);

   /* emit a detailed log message */
   jk_log(l, JK_LOG_INFO,
  "(%s) Request to (%s %s) started at %s,%ld",
  ae->worker->name, r->method, r->req_uri, timestamp, 
r->r->request_time.tm_usec);


Does anyone think this might be generally useful?


It looks like I needed a few more things in order to get this to work:

   {
     char *timestamp = malloc(32);
     apr_time_exp_t *timerec = malloc(sizeof(apr_time_exp_t));
     apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;
     apr_time_exp_gmt(timerec, ap->r->request_time);
     apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", timerec);
     /* emit a detailed log message */
     jk_log(l, JK_LOG_INFO,
    "(%s) Request to (%s %s) started at %s",
    ae->worker->name, r->method, r->req_uri, timestamp);
     free(timerec);
     free(timestamp);
   }

The compiler wouldn't let me use an automatically-allocated char[32] so 
I had to malloc it. I also had to convert from long to apr_time_exp_t 
which required another structure/malloc as well.


Finally, I had to cast the r->ws_private to apache_private_data_t* which 
required me to copy/paste the definition of apache_private_data_t from 
mod_jk.h into jk_ajp_common.c -- just as a test for now.


Obviously, this works only for Apache httpd.

I have it running on one of my web servers for now -- hoping to catch an 
error and see this additional logging to see if it's helpful to me. (LOL 
just segfaulted; time to go back and look.)


What would be the best way to get the "start time" of the request in a 
platform-independent way? Maybe just expand the jk_ws_service structure 
to include it?


Apart from the info chuck send via PM, I think it would be better to try 
to add a unique request ID as a correlation ID. Apache can already 
generate them using mod_unique_id and you can add them there to the 
access log.


Now how could we make that ID accessible from mod_jk?

We could either add it as a new item to jk_ws_service and I think it 
would be a good fit. Any server not yet providing it, eg. if we find no 
way adding it in IIS, would have a null value there (or some constant we 
init it to). We are free to add things, because we do not really provide 
a public API used elsewhere which we need to keep stable.


When we do logging in mod_jk, we use jk_log(jk_logger_t *l, ...) where 
the remaining arguments are just standard log arguments. We could add a 
new jk_request_log(jk_logger_t *l, jk_ws_service_t *s, ...) and that 
function retrieves the request ID from s and adds it to the log line.


It seems, typically where we want to log something that would benefit 
from a request ID, we have the jk_ws_service_t at hand, so could add it 
to the log call.


WDYT?

Best regards,

Rainer

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

Upgrade tomcat 7 to 10.

2022-05-26 Thread Rodrigo Cunha

Hi,
i need upgrade my tomcat server from 7 to 10. I don't saw in internet
nothing about that. Commonly i upgraded in steps, 7 to 8, 8 to 9 and 9 to
10.
Are there a problem upgrade from 7 to 10?

-- 
Atenciosamente,
Rodrigo da Silva Cunha
São Gonçalo, RJ - Brasil

Re: Sv: Unexpected messages in commons-daemon.log

2022-05-26 Thread Christopher Schultz


Pontus,

On 5/25/22 03:53, Pontus Ågren wrote:

There is monitoring of the service so that seems to be the cause. I
agree that logging it at TRACE level is a better idea. On INFO level
it just adds noice.
You might be "over monitoring" if you are seeing pairs of messages at 
once... except for every 5 minutes (which seems odd).


Are you maybe checking this service twice a minute instead of once per 
minute as (probably) expected?


-chris

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

Re: What causes "client errors" with mod_jk

2022-05-26 Thread Christopher Schultz


Rainer,

On 5/26/22 16:46, Rainer Jung wrote:

Hi Chris,

Am 16.05.2022 um 19:48 schrieb Christopher Schultz:

I've been looking into this a little more in my production environment.

These errors are not super common, but there seems to be a steady 
trickle of errors from my two services that have human users. I see 0 
errors for my API-based services, which makes me think that I don't 
have any performance issues... I probably have human users 
disappearing for random reasons.


Could be unstable (mobile) client connections. Or people already 
clicking on the next frontend action before they received the complete 
response. But that is speculating. So it is right, you try to identify 
some individual reasons to understand more.



The errors in mod_jk.log look like this:

[Sun May 15 04:19:15.643 2022] [5859:139625025315392] [info] 
ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to 
client aborted or client network problems
[Sun May 15 04:19:15.644 2022] [5859:139625025315392] [info] 
ajp_service::jk_ajp_common.c (2773): (myworker) sending request to 
tomcat failed (unrecoverable), because of client write error (attempt=1)
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1595): service failed, worker myworker is in 
local error state
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1614): unrecoverable error 200, request 
failed. Client failed in the middle of request, we can't recover to 
another instance.
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker


(Note that the last message "Aborting connection for worker=myworker" 
may have a bug; my actual worker name has a name containing a hyphen 
(-) and only the text before the hyphen is being emitted in that error 
message.)


Strange, never observed that, but maybe never used a hyphen. Docs say, 
hypens are allowed. Would be interesting to do a server startup with 
trace-Logging and see where things corresponding to the name start to go 
wrong. But of course not related to sporadic client failures.


Right. I may investigate that separately, as I have a setup already with 
everything in place.


Anyway, when researching these errors, it would be helpful to me to 
know which requests are failing. By looking at the access_log, I only 
see a single request logged for 04:19:15 on that server so it's 
probably the right one, but httpd says that the response code is 302 
instead of e.g. 50x for an error.


What I typically do:

- log "%P:%{tid}P" in your Apache httpd custom LogFormat used for the 
access log.


- make sure, I log in in the Apache httpd access log the request 
timestamp including milli or microseconds (not default but 
configurable). Can be done by using the %{format}t syntax in the 
LogFormat and adding "usec_frac" to the format.


- adding %D to the access log format (duration in microseconds)

- remember that Apache logs start of request as default time stamp, but 
mod_jk logs at the moment of error, so later than start of request.


Finding the right access log line for a mod_jk error log line now means:

- filter the access log according to the PID:TID logged in the mod_jk 
error log. In your case 5859:139625025315392. We know, that the requests 
handled by one thread in one process are run strictly sequentially.


- look for the last request in this filtered list, that by access log 
line timestamp started before (or unlikely exactly at) the point in time 
given by the mod_jk access log. If you find one exactly add, it might be 
also the one directly before.


- look at the request durations of these one or two requests to double 
check, whether the times fit.


If you can spare the additional log line bytes, you can additionally log 
the end of request timestamp in the apache access log (prefix "format" 
by "begin:").


Especially by adding this "enhanced logging", it was very easy to find 
the failing requests.


Fortunately for me, the JK log is "now" and the request_time is the 
start-of-request, so I can see the delay between the two. In the cases 
I've seen since I started watching the log, it's typically a very short 
tie like 1-2 sec which shouldn't be something a user gets tired waiting for.


I was more worried like "mod_jk waited 35 seconds for a response from 
upstream and the user went away" and that's not the case.


So I'm happy to find that the reason for these errors is pathological 
user behavior and not some performance problem on my end.


Thanks,
-chris

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

Re: What causes "client errors" with mod_jk

2022-05-26 Thread Christopher Schultz


All,

On 5/26/22 15:49, Christopher Schultz wrote:

Rainer,

On 5/16/22 13:48, Christopher Schultz wrote:

Rainer,

I've been looking into this a little more in my production environment.

These errors are not super common, but there seems to be a steady 
trickle of errors from my two services that have human users. I see 0 
errors for my API-based services, which makes me think that I don't 
have any performance issues... I probably have human users 
disappearing for random reasons.


The errors in mod_jk.log look like this:

[Sun May 15 04:19:15.643 2022] [5859:139625025315392] [info] 
ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to 
client aborted or client network problems
[Sun May 15 04:19:15.644 2022] [5859:139625025315392] [info] 
ajp_service::jk_ajp_common.c (2773): (myworker) sending request to 
tomcat failed (unrecoverable), because of client write error (attempt=1)
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1595): service failed, worker myworker is in 
local error state
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1614): unrecoverable error 200, request 
failed. Client failed in the middle of request, we can't recover to 
another instance.
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker


(Note that the last message "Aborting connection for worker=myworker" 
may have a bug; my actual worker name has a name containing a hyphen 
(-) and only the text before the hyphen is being emitted in that error 
message.)


Anyway, when researching these errors, it would be helpful to me to 
know which requests are failing. By looking at the access_log, I only 
see a single request logged for 04:19:15 on that server so it's 
probably the right one, but httpd says that the response code is 302 
instead of e.g. 50x for an error.


When we log these kinds of errors, it would be great to know a few 
things IMO:


1. What was the URL of the request
2. How long did the client wait for the response before we found we 
couldn't write to the stream (or, conversely, the start-timestamp of 
the request as well as the timestamp of the error, which I think is 
already in the log itself)


I see the place in the code where the error is generated, but I'm not 
familiar enough with the code to know how to add that kind of thing. 
The function in question (ajp_process_callback) has a pointer to a 
jk_ws_service_t structure. Is it as simple as also logging like this?


   /* convert start-time to a string */
   char[32] timestamp;
   apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", 
r->r->request_time);

   /* emit a detailed log message */
   jk_log(l, JK_LOG_INFO,
  "(%s) Request to (%s %s) started at %s,%ld",
  ae->worker->name, r->method, r->req_uri, timestamp, 
r->r->request_time.tm_usec);


Does anyone think this might be generally useful?


It looks like I needed a few more things in order to get this to work:

   {
     char *timestamp = malloc(32);
     apr_time_exp_t *timerec = malloc(sizeof(apr_time_exp_t));
     apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;
     apr_time_exp_gmt(timerec, ap->r->request_time);
     apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", timerec);
     /* emit a detailed log message */
     jk_log(l, JK_LOG_INFO,
    "(%s) Request to (%s %s) started at %s",
    ae->worker->name, r->method, r->req_uri, timestamp);
     free(timerec);
     free(timestamp);
   }

The compiler wouldn't let me use an automatically-allocated char[32] so 
I had to malloc it. I also had to convert from long to apr_time_exp_t 
which required another structure/malloc as well.


Finally, I had to cast the r->ws_private to apache_private_data_t* which 
required me to copy/paste the definition of apache_private_data_t from 
mod_jk.h into jk_ajp_common.c -- just as a test for now.


Obviously, this works only for Apache httpd.

I have it running on one of my web servers for now -- hoping to catch an 
error and see this additional logging to see if it's helpful to me. (LOL 
just segfaulted; time to go back and look.)


What would be the best way to get the "start time" of the request in a 
platform-independent way? Maybe just expand the jk_ws_service structure 
to include it?


Here is my latest code which hasn't segfaulted in a while:

{
  /* emit a detailed log message */
  char timestamp[32]; // For formatted timestamp string
  apr_time_exp_t timerec; // Required for apr_strftime
  apr_size_t retsize; // Required for apr_strftime
  apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;

  apr_time_exp_gmt(, ap->r->request_time); // Convert 
request_time to apr_time_exp_t
  apr_strftime(timestamp, , 32, "%Y-%m-%d %H:%M:%S", ); 
// Format the timestamp

  if(0 == retsize) {
strcpy(timestamp, "(overflow)");
  }

  jk_log(l, JK_LOG_INFO,

Re: What causes "client errors" with mod_jk

2022-05-26 Thread Rainer Jung


Hi Chris,

Am 16.05.2022 um 19:48 schrieb Christopher Schultz:

I've been looking into this a little more in my production environment.

These errors are not super common, but there seems to be a steady 
trickle of errors from my two services that have human users. I see 0 
errors for my API-based services, which makes me think that I don't have 
any performance issues... I probably have human users disappearing for 
random reasons.


Could be unstable (mobile) client connections. Or people already 
clicking on the next frontend action before they received the complete 
response. But that is speculating. So it is right, you try to identify 
some individual reasons to understand more.



The errors in mod_jk.log look like this:

[Sun May 15 04:19:15.643 2022] [5859:139625025315392] [info] 
ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to 
client aborted or client network problems
[Sun May 15 04:19:15.644 2022] [5859:139625025315392] [info] 
ajp_service::jk_ajp_common.c (2773): (myworker) sending request to 
tomcat failed (unrecoverable), because of client write error (attempt=1)
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1595): service failed, worker myworker is in 
local error state
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1614): unrecoverable error 200, request failed. 
Client failed in the middle of request, we can't recover to another 
instance.
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker


(Note that the last message "Aborting connection for worker=myworker" 
may have a bug; my actual worker name has a name containing a hyphen (-) 
and only the text before the hyphen is being emitted in that error 
message.)


Strange, never observed that, but maybe never used a hyphen. Docs say, 
hypens are allowed. Would be interesting to do a server startup with 
trace-Logging and see where things corresponding to the name start to go 
wrong. But of course not related to sporadic client failures.


Anyway, when researching these errors, it would be helpful to me to know 
which requests are failing. By looking at the access_log, I only see a 
single request logged for 04:19:15 on that server so it's probably the 
right one, but httpd says that the response code is 302 instead of e.g. 
50x for an error.


What I typically do:

- log "%P:%{tid}P" in your Apache httpd custom LogFormat used for the 
access log.


- make sure, I log in in the Apache httpd access log the request 
timestamp including milli or microseconds (not default but 
configurable). Can be done by using the %{format}t syntax in the 
LogFormat and adding "usec_frac" to the format.


- adding %D to the access log format (duration in microseconds)

- remember that Apache logs start of request as default time stamp, but 
mod_jk logs at the moment of error, so later than start of request.


Finding the right access log line for a mod_jk error log line now means:

- filter the access log according to the PID:TID logged in the mod_jk 
error log. In your case 5859:139625025315392. We know, that the requests 
handled by one thread in one process are run strictly sequentially.


- look for the last request in this filtered list, that by access log 
line timestamp started before (or unlikely exactly at) the point in time 
given by the mod_jk access log. If you find one exactly add, it might be 
also the one directly before.


- look at the request durations of these one or two requests to double 
check, whether the times fit.


If you can spare the additional log line bytes, you can additionally log 
the end of request timestamp in the apache access log (prefix "format" 
by "begin:").


When we log these kinds of errors, it would be great to know a few 
things IMO:


1. What was the URL of the request
2. How long did the client wait for the response before we found we 
couldn't write to the stream (or, conversely, the start-timestamp of the 
request as well as the timestamp of the error, which I think is already 
in the log itself)


I see the place in the code where the error is generated, but I'm not 
familiar enough with the code to know how to add that kind of thing. The 
function in question (ajp_process_callback) has a pointer to a 
jk_ws_service_t structure. Is it as simple as also logging like this?


   /* convert start-time to a string */
   char[32] timestamp;
   apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", 
r->r->request_time);

   /* emit a detailed log message */
   jk_log(l, JK_LOG_INFO,
  "(%s) Request to (%s %s) started at %s,%ld",
  ae->worker->name, r->method, r->req_uri, timestamp, 
r->r->request_time.tm_usec);


Does anyone think this might be generally useful?


I'll have a look at your other mail on this next.

Best regards,

Rainer


Thanks,
-chris

On 3/25/22 08:37, Christopher Schultz wrote:

Rainer,

On 3/24/22

Re: What causes "client errors" with mod_jk

2022-05-26 Thread Christopher Schultz


Rainer,

On 5/16/22 13:48, Christopher Schultz wrote:

Rainer,

I've been looking into this a little more in my production environment.

These errors are not super common, but there seems to be a steady 
trickle of errors from my two services that have human users. I see 0 
errors for my API-based services, which makes me think that I don't have 
any performance issues... I probably have human users disappearing for 
random reasons.


The errors in mod_jk.log look like this:

[Sun May 15 04:19:15.643 2022] [5859:139625025315392] [info] 
ajp_process_callback::jk_ajp_common.c (2077): (myworker) Writing to 
client aborted or client network problems
[Sun May 15 04:19:15.644 2022] [5859:139625025315392] [info] 
ajp_service::jk_ajp_common.c (2773): (myworker) sending request to 
tomcat failed (unrecoverable), because of client write error (attempt=1)
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1595): service failed, worker myworker is in 
local error state
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
service::jk_lb_worker.c (1614): unrecoverable error 200, request failed. 
Client failed in the middle of request, we can't recover to another 
instance.
[Sun May 15 04:19:15.646 2022] [5859:139625025315392] [info] 
jk_handler::mod_jk.c (2984): Aborting connection for worker=myworker


(Note that the last message "Aborting connection for worker=myworker" 
may have a bug; my actual worker name has a name containing a hyphen (-) 
and only the text before the hyphen is being emitted in that error 
message.)


Anyway, when researching these errors, it would be helpful to me to know 
which requests are failing. By looking at the access_log, I only see a 
single request logged for 04:19:15 on that server so it's probably the 
right one, but httpd says that the response code is 302 instead of e.g. 
50x for an error.


When we log these kinds of errors, it would be great to know a few 
things IMO:


1. What was the URL of the request
2. How long did the client wait for the response before we found we 
couldn't write to the stream (or, conversely, the start-timestamp of the 
request as well as the timestamp of the error, which I think is already 
in the log itself)


I see the place in the code where the error is generated, but I'm not 
familiar enough with the code to know how to add that kind of thing. The 
function in question (ajp_process_callback) has a pointer to a 
jk_ws_service_t structure. Is it as simple as also logging like this?


   /* convert start-time to a string */
   char[32] timestamp;
   apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", 
r->r->request_time);

   /* emit a detailed log message */
   jk_log(l, JK_LOG_INFO,
  "(%s) Request to (%s %s) started at %s,%ld",
  ae->worker->name, r->method, r->req_uri, timestamp, 
r->r->request_time.tm_usec);


Does anyone think this might be generally useful?


It looks like I needed a few more things in order to get this to work:

  {
char *timestamp = malloc(32);
apr_time_exp_t *timerec = malloc(sizeof(apr_time_exp_t));
apache_private_data_t *ap = (apache_private_data_t*)r->ws_private;
apr_time_exp_gmt(timerec, ap->r->request_time);
apr_strftime(timestamp, NULL, 32, "%Y-%m-%d %H:%M:%S", timerec);
/* emit a detailed log message */
jk_log(l, JK_LOG_INFO,
   "(%s) Request to (%s %s) started at %s",
   ae->worker->name, r->method, r->req_uri, timestamp);
free(timerec);
free(timestamp);
  }

The compiler wouldn't let me use an automatically-allocated char[32] so 
I had to malloc it. I also had to convert from long to apr_time_exp_t 
which required another structure/malloc as well.


Finally, I had to cast the r->ws_private to apache_private_data_t* which 
required me to copy/paste the definition of apache_private_data_t from 
mod_jk.h into jk_ajp_common.c -- just as a test for now.


Obviously, this works only for Apache httpd.

I have it running on one of my web servers for now -- hoping to catch an 
error and see this additional logging to see if it's helpful to me. (LOL 
just segfaulted; time to go back and look.)


What would be the best way to get the "start time" of the request in a 
platform-independent way? Maybe just expand the jk_ws_service structure 
to include it?


-chris

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

Re: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix

2022-05-26 Thread Mark Thomas


On 26/05/2022 14:29, Ralph Atallah wrote:

Hi Mark,

What we are trying to do is to prevent Host header attacks by ensuring that the host name 
in the http request URL always matches the "Host" header in the request.  If it 
does not, we are supposed refuse the request and respond with 400 Bad Request as per 
OWASP recommendations.   Here are some examples:

Normal request
GET http://example.com/myapp
Host: example.com
Expected response:  200 OK

Request with a host header attack
GET http://example.com/myapp
Host: attacker.com
Expected response:  400 Bad Request

The AbstracktHttp11Processor.java class seems to be doing exactly that in the 
code snippet below:

if (allowHostHeaderMismatch) {
  // The requirements of RFC 2616 are being
  // applied. If the host header and the request
  // line do not agree, the request line takes
  // precedence
  hostValueMB = headers.setValue("host");
  hostValueMB.setBytes(uriB, uriBCStart + pos, slashPos - pos);
  } else {
   // The requirements of RFC 7230 are being
   // applied. If the host header and the request
   // line do not agree, trigger a 400 response.
   badRequest("http11processor.request.inconsistentHosts");
  }

However, this portion of the code is never reached for the reason mentioned in 
the previous email.

By the time the request reaches our application, the 
HttpServletRequest.getRequestURL() returns  http://attacker.com/myapp instead 
of http://example.com/myapp
We have enabled the AccessLogValve in server.xml in the hope to see the URL 
that reaches tomcat, but it seems that we only get the relative URL there, 
never the absolute one, i.e. we only see /myapp when we print %u for example.

Any tips in this area would be much appreciated.


If the original request only has a Host header, then 
allowHostHeaderMismatch="false" isn't going to do anything because there 
is no mismatch.


If you want to reject requests that have a Host header that isn't one 
you recognize then there are multiple options:


- write a Filter
- write a Valve
- configure a Host (or several) for the requests you want to allow and
  deploy an ROOT to the default host that rejects everything else.

Mark




Ralph

-Original Message-
From: Mark Thomas 
Sent: Thursday, May 26, 2022 3:24 AM
To: users@tomcat.apache.org
Subject: Re: allowHostHeaderMismatch option only works if the Host Header has 
an http or https prefix

WARNING: This email originated from outside of CallMiner. Do not click any links or 
open any attachments unless you recognize the sender and know that the content is 
safe. Please report suspicious emails to: reportsuspiciousema...@callminer.com 


On 26/05/2022 02:20, Ralph Atallah wrote:

Hi,

We use Tomcat 7.0.109 and Tomcat 8.5 in our Tomcat based webapp deployments and 
we have a new requirement to prevent Host Header injection.  The 
allowHostHeaderMismatch option seems the perfect answer to this issue.  
However, configuring it in our environment, i.e. in the server.xml connector 
tag still does not seem to make it work.

Debugging the code, we see that the check for this setting is never even 
reached in the 
org.apache.coyote.http11.AbstractHttp11Processor.prepareRequest() method.  The 
reason is in the code snippet below:

   ByteChunk uriBC = request.requestURI().getByteChunk();
   byte[] uriB = uriBC.getBytes();
   if (uriBC.startsWithIgnoreCase("http", 0)) {
 ...
  if (allowHostHeaderMismatch) {
 ...
  }
}

uriBC does not contain the full URL such as http://localhost:8080/myapp, but rather only 
the /myapp path, so that if (uriBC.startsWithIgnoreCase("http", 0)) condition 
is never met.

We are probably missing something very basic, and would really appreciate some 
guidance.


I suspect that allowHostHeaderMismatch doesn't do what you think it does.

Exactly what problem are you trying to solve when so say you want to prevent "Host 
header injection"?

Mark

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


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



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

Re: Logging "location" header from the HTTP response

2022-05-26 Thread Robert Hicks

On Thu, May 26, 2022 at 11:37 AM Konstantin Kolinko 
wrote:

> чт, 26 мая 2022 г. в 18:19, Robert Hicks :
> >
> > We would like to start logging the response location in Tomcat. I am not
> > sure where to look something like that up.
>
> You are not mentioning the version number, but from other threads I
> assume that it is 9.0.x.
>
> Here:
> https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Log_Valve
>
> Look for "%{xxx}o"
>
> Best regards,
> Konstantin Kolinko
>

Thanks! I see how to do it now.

Bob

Re: Logging "location" header from the HTTP response

2022-05-26 Thread Konstantin Kolinko

чт, 26 мая 2022 г. в 18:19, Robert Hicks :
>
> We would like to start logging the response location in Tomcat. I am not
> sure where to look something like that up.

You are not mentioning the version number, but from other threads I
assume that it is 9.0.x.

Here:
https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Log_Valve

Look for "%{xxx}o"

Best regards,
Konstantin Kolinko

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

Logging "location" header from the HTTP response

2022-05-26 Thread Robert Hicks

We would like to start logging the response location in Tomcat. I am not
sure where to look something like that up.

Thanks,

Bob

RE: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix

2022-05-26 Thread Ralph Atallah

Hi Mark,

What we are trying to do is to prevent Host header attacks by ensuring that the 
host name in the http request URL always matches the "Host" header in the 
request.  If it does not, we are supposed refuse the request and respond with 
400 Bad Request as per OWASP recommendations.   Here are some examples:

Normal request
   GET http://example.com/myapp
   Host: example.com
   Expected response:  200 OK 

Request with a host header attack
   GET http://example.com/myapp
   Host: attacker.com
   Expected response:  400 Bad Request

The AbstracktHttp11Processor.java class seems to be doing exactly that in the 
code snippet below:

   if (allowHostHeaderMismatch) {
 // The requirements of RFC 2616 are being
 // applied. If the host header and the request
 // line do not agree, the request line takes
 // precedence
 hostValueMB = headers.setValue("host");
 hostValueMB.setBytes(uriB, uriBCStart + pos, slashPos - pos);
 } else {
  // The requirements of RFC 7230 are being
  // applied. If the host header and the request
  // line do not agree, trigger a 400 response.
  badRequest("http11processor.request.inconsistentHosts");
 }

However, this portion of the code is never reached for the reason mentioned in 
the previous email.

By the time the request reaches our application, the 
HttpServletRequest.getRequestURL() returns  http://attacker.com/myapp instead 
of http://example.com/myapp
We have enabled the AccessLogValve in server.xml in the hope to see the URL 
that reaches tomcat, but it seems that we only get the relative URL there, 
never the absolute one, i.e. we only see /myapp when we print %u for example.  

Any tips in this area would be much appreciated.
Ralph

-Original Message-
From: Mark Thomas  
Sent: Thursday, May 26, 2022 3:24 AM
To: users@tomcat.apache.org
Subject: Re: allowHostHeaderMismatch option only works if the Host Header has 
an http or https prefix

WARNING: This email originated from outside of CallMiner. Do not click any 
links or open any attachments unless you recognize the sender and know that the 
content is safe. Please report suspicious emails to: 
reportsuspiciousema...@callminer.com 

On 26/05/2022 02:20, Ralph Atallah wrote:
> Hi,
>
> We use Tomcat 7.0.109 and Tomcat 8.5 in our Tomcat based webapp deployments 
> and we have a new requirement to prevent Host Header injection.  The 
> allowHostHeaderMismatch option seems the perfect answer to this issue.  
> However, configuring it in our environment, i.e. in the server.xml connector 
> tag still does not seem to make it work.
>
> Debugging the code, we see that the check for this setting is never even 
> reached in the 
> org.apache.coyote.http11.AbstractHttp11Processor.prepareRequest() method.  
> The reason is in the code snippet below:
>
>   ByteChunk uriBC = request.requestURI().getByteChunk();
>   byte[] uriB = uriBC.getBytes();
>   if (uriBC.startsWithIgnoreCase("http", 0)) {
> ...
>  if (allowHostHeaderMismatch) {
> ...
>  }
> }
>
> uriBC does not contain the full URL such as http://localhost:8080/myapp, but 
> rather only the /myapp path, so that if (uriBC.startsWithIgnoreCase("http", 
> 0)) condition is never met.
>
> We are probably missing something very basic, and would really appreciate 
> some guidance.

I suspect that allowHostHeaderMismatch doesn't do what you think it does.

Exactly what problem are you trying to solve when so say you want to prevent 
"Host header injection"?

Mark

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

Re: [External] Re: Maximum header size in Tomcat 9

2022-05-26 Thread Mark Thomas


On 25/05/2022 16:21, Amit Pande wrote:

Hello Mark,

Could we slightly update the description - to say that this size is total size 
(in bytes)of all the request (and response) headers combined (including the 
header name and values)?
In the past, I incorrectly assumed that this size limit applies for one header 
value.

maxHttpHeaderSize
The maximum size of the request and response HTTP header, specified in bytes. 
If not specified, this attribute is set to 8192 (8 KB).


Done.

Mark




Thanks,
Amit

-Original Message-
From: Mark Thomas 
Sent: Wednesday, May 25, 2022 6:16 AM
To: users@tomcat.apache.org
Subject: [External] Re: Maximum header size in Tomcat 9

On 25/05/2022 12:08, Aditya Kumar wrote:

Thanks! Sorry I misread that article.

So I suppose it's the same for maxHttpRequestHeaderSize and
maxHttpResponseHeaderSize?


Correct.

Mark






On Wed, May 25, 2022 at 10:45 AM Mark Thomas  wrote:


On 25/05/2022 10:33, Aditya Kumar wrote:

I'm sorry I'm not sure what you mean by Integer.MAX_VALUE?


https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc
s.oracle.com%2Fjavase%2F8%2Fdocs%2Fapi%2Fjava%2Flang%2FInteger.html%2
3MAX_VALUEdata=05%7C01%7CAmit.Pande%40veritas.com%7Ce18ae152bff0
402dad6908da3e3ff7e3%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637
890741724402644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=pfV4K
ul5InBqXlyW958TnV57bbZbe6F%2FrurIJqJ70xg%3Dreserved=0


Looking at
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fto
mcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Fhttp.htmldata=05%7C
01%7CAmit.Pande%40veritas.com%7Ce18ae152bff0402dad6908da3e3ff7e3%7Cf
c8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637890741724402644%7CUnkno
wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
iLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=VXFY%2Bew8f1HxXiUYsyCmgiVD
B%2FqQUJr4rhbB8LbZmkA%3Dreserved=0

all I

see is this:-
"maxHttpHeaderSize

The maximum size of the request and response HTTP header, specified
in bytes. If not specified, this attribute is set to 8192 (8 KB)."
This does not explain possible values. Can you give me an actual
number

for

the maximum?


See above.

The theoretical maximum is so far above any sensible value there is
not much point documenting it.


Also I saw in this article:


https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom
munity.jaspersoft.com%2Fwiki%2Fhow-pass-big-number-values-apache-tomc
at-url-stringdata=05%7C01%7CAmit.Pande%40veritas.com%7Ce18ae152b
ff0402dad6908da3e3ff7e3%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C
637890741724402644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=I6
%2FHM6WSIVucDyEU17ENL0NGNbBDqtAEZ2snU6FFUF4%3Dreserved=0


" A value of less than 0 means no limit."


That text is copied directly from the Tomcat documentation and is
part of the description for maxParameterCount, not maxHttpHeaderSize.
What makes you think it might apply to maxHttpHeaderSize?

Mark





On Wed, May 25, 2022 at 10:19 AM Mark Thomas  wrote:


On 25/05/2022 09:51, Aditya Kumar wrote:

Hi

I'm using Tomcat 9.0.46 and I want to know what is the maximum
possible value for maxHttpHeaderSize


Integer.MAX_VALUE


I have Tomcat setup using kerberos authentication and for some
users

the

Authorisation header is too large (too many AD groups).

I have seen various articles when googling but I want something
from official documentation to state what the possible values for
this field are. Is it true that setting a value of "-1" causes a
limitless maximum header size value?


Where did you read that? I don't see that in the documentation.

Mark

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






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






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


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



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

Re: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix

2022-05-26 Thread Mark Thomas


On 26/05/2022 02:20, Ralph Atallah wrote:

Hi,

We use Tomcat 7.0.109 and Tomcat 8.5 in our Tomcat based webapp deployments and 
we have a new requirement to prevent Host Header injection.  The 
allowHostHeaderMismatch option seems the perfect answer to this issue.  
However, configuring it in our environment, i.e. in the server.xml connector 
tag still does not seem to make it work.

Debugging the code, we see that the check for this setting is never even 
reached in the 
org.apache.coyote.http11.AbstractHttp11Processor.prepareRequest() method.  The 
reason is in the code snippet below:

  ByteChunk uriBC = request.requestURI().getByteChunk();
  byte[] uriB = uriBC.getBytes();
  if (uriBC.startsWithIgnoreCase("http", 0)) {
...
 if (allowHostHeaderMismatch) {
...
 }
}

uriBC does not contain the full URL such as http://localhost:8080/myapp, but rather only 
the /myapp path, so that if (uriBC.startsWithIgnoreCase("http", 0)) condition 
is never met.

We are probably missing something very basic, and would really appreciate some 
guidance.


I suspect that allowHostHeaderMismatch doesn't do what you think it does.

Exactly what problem are you trying to solve when so say you want to 
prevent "Host header injection"?


Mark

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

Re: Upgrade tomcat 7 to 10.

RE: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix

Re: Upgrade tomcat 7 to 10.

Re: What causes "client errors" with mod_jk

Re: Upgrade tomcat 7 to 10.

Re: What causes "client errors" with mod_jk

Upgrade tomcat 7 to 10.

Re: Sv: Unexpected messages in commons-daemon.log

Re: What causes "client errors" with mod_jk

Re: What causes "client errors" with mod_jk

Re: What causes "client errors" with mod_jk

Re: What causes "client errors" with mod_jk

Re: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix

Re: Logging "location" header from the HTTP response

Re: Logging "location" header from the HTTP response

Logging "location" header from the HTTP response

RE: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix

Re: [External] Re: Maximum header size in Tomcat 9

Re: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix

19 matches

Site Navigation

Mail list logo

Footer information