On 31/03/2020 14:36, Manuel Dominguez Sarmiento wrote:
> Thanks, so we would be able to log this with AccessLogValve using the
> following patterns, right?
> %{org.apache.coyote.connectionID}r
> %{org.apache.coyote.streamID}r
Correct.
Mark
>
> *Manuel Dominguez Sarmiento*
>
> On 31/03/2020
Thanks, so we would be able to log this with AccessLogValve using the
following patterns, right?
%{org.apache.coyote.connectionID}r
%{org.apache.coyote.streamID}r
*Manuel Dominguez Sarmiento*
On 31/03/2020 10:28, Mark Thomas wrote:
On 29/03/2020 16:16, Mark Thomas wrote:
On 29/03/2020 15:58,
On 29/03/2020 16:16, Mark Thomas wrote:
> On 29/03/2020 15:58, Manuel Dominguez Sarmiento wrote:
>>
>>> Do the streams with errors all share the same connection ID? I suspect
>>> an error on one stream is triggering the closure of the connection and
>>> what you are seeing is the fallout of
On 29/03/2020 15:58, Manuel Dominguez Sarmiento wrote:
>
>> Do the streams with errors all share the same connection ID? I suspect
>> an error on one stream is triggering the closure of the connection and
>> what you are seeing is the fallout of closing the connection.
> That makes sense and is
Do the streams with errors all share the same connection ID? I suspect
an error on one stream is triggering the closure of the connection and
what you are seeing is the fallout of closing the connection.
That makes sense and is kind of what we're suspecting. How can we check
the
On 28/03/2020 14:00, Manuel Dominguez Sarmiento wrote:
> Hi Mark, we're now on the latest 9.0.33 release and we still see this
> issue intermittently in our logs. Only on HTTP/2 secure requests.
>
> Please see the attached access logs (these represent all the cases for
> one whole day in one
Hi Mark, we're now on the latest 9.0.33 release and we still see this
issue intermittently in our logs. Only on HTTP/2 secure requests.
Please see the attached access logs (these represent all the cases for
one whole day in one single high-volume server).
Some of the following request fields
Hi Christopher, please see below:
1) The Tomcat valves operate on all webapps. We only need/require
this for one particular webapp without affecting the others.
Not true; see Konstantin's response.
Yes, I realized per-context valve configuration was possible after I
sent my original email.
Hi Konstantin, please see below:
You can configure a Valve for a specific web application by placing it
into Context configuration for that specific web application (usually
that is the "/META-INF/context.xml" configuration file). [1]
[1]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Manuel,
On 2/5/20 1:29 PM, Manuel Dominguez Sarmiento wrote:
> Yes, there are two reasons:
>
> 1) The Tomcat valves operate on all webapps. We only need/require
> this for one particular webapp without affecting the others.
Not true; see
ср, 5 февр. 2020 г. в 21:29, Manuel Dominguez Sarmiento :
>
> Yes, there are two reasons:
>
> 1) The Tomcat valves operate on all webapps. We only need/require this
> for one particular webapp without affecting the others.
You can configure a Valve for a specific web application by placing it
Yes, there are two reasons:
1) The Tomcat valves operate on all webapps. We only need/require this
for one particular webapp without affecting the others.
2) The code has been simplified for illustration purposes. Besides
X-Forwarded-For, we detect and work around many other custom external
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Manuel,
On 2/5/20 12:12 PM, Manuel Dominguez Sarmiento wrote:
> Our filter is not doing anything fancy (and it has always worked
> correctly before we ran into this bug). In pseudo-code:
>
> public doFilter(request, response) {
>
> String ip =
Our filter is not doing anything fancy (and it has always worked
correctly before we ran into this bug). In pseudo-code:
public doFilter(request, response) {
String ip = request.getRemoteAddr();
boolean isProxy = isProxy(ip);
if (isProxy) {
String unwrappedIP =
On 04/02/2020 22:27, Manuel Dominguez Sarmiento wrote:
> We are getting the NPEs in a top-of-the-chain servlet filter which
> decorates HttpServletRequest.getRemoteAddr() before actual servlet
> processing. Only on HTTP/2 and in a very small number of cases. Perhaps
> we should test 9.0.31 and see
We are getting the NPEs in a top-of-the-chain servlet filter which
decorates HttpServletRequest.getRemoteAddr() before actual servlet
processing. Only on HTTP/2 and in a very small number of cases. Perhaps
we should test 9.0.31 and see what happens. When is this new version due
for release?
On 04/02/2020 15:37, Manuel Dominguez Sarmiento wrote:
> Thanks Mark. I just wanted to clarify that the issue is not only present
> when the request arrives at AccessLogValve, but while the request is
> being serviced as well.
> We noticed this bug because we were getting random
Thanks Mark. I just wanted to clarify that the issue is not only present
when the request arrives at AccessLogValve, but while the request is
being serviced as well.
We noticed this bug because we were getting random NullPointerExceptions
when trying to do anything with the result from
On 03/02/2020 19:24, Mark Thomas wrote:
> I haven't fixed this but I can reproduce it easily with the h2spec test
> suite. As I have a reproducible test case I'm hopeful I'll be able to
> find a fix fairly quickly.
I've just committed a fix. It is in:
- master for 10.0.0.0-M1 onwards
- 9.0.x
On 24/01/2020 12:26, Manuel Dominguez Sarmiento wrote:
> Hi Mark, thanks for your feedback. Please see below:
>> On 23/01/2020 13:40, Manuel Dominguez Sarmiento wrote:
>>> Hi, we started
>>> noticing that HttpServletRequest.getRemoteAddr() was
>>> sometimes returning NULL (which is invalid
Hi Mark, thanks for your feedback. Please see below:
On 23/01/2020 13:40, Manuel Dominguez Sarmiento wrote:> Hi, we started
noticing that HttpServletRequest.getRemoteAddr() was
sometimes returning NULL (which is invalid according to the servlet
spec), about 20-50 times per day (we have
On 23/01/2020 13:40, Manuel Dominguez Sarmiento wrote:> Hi, we started
noticing that HttpServletRequest.getRemoteAddr() was
> sometimes returning NULL (which is invalid according to the servlet
> spec), about 20-50 times per day (we have high-load servers which
> routinely handle over 100 requests
Hi, we started noticing that HttpServletRequest.getRemoteAddr() was
sometimes returning NULL (which is invalid according to the servlet
spec), about 20-50 times per day (we have high-load servers which
routinely handle over 100 requests per second). This only happens on
secure HTTP/2 requests.
23 matches
Mail list logo
