Re: Support with error in launcher.log

[Svetlin Zarev]

Hi,

We've had this error and it turned out to be due to the cookie processor.
According to RFC6265, the domain attribute of the cookie must not start
with a dot, so the new cookie processor rejects those cookies. Either
remove the starting dot from the domain attribute or use the legacy cookie
processor.

Kind regards,
Svetlin

На пн, 30.03.2020 г. в 13:22 Martin Grigorov  написа:

> Hi,
>
> On Mon, Mar 30, 2020 at 1:02 PM Luigi Tagliafierro <
> ltagliafie...@doxee.com> wrote:
>
>> Hi everybody,
>>
>> we are experiencing an error :  The bitbucket log
>> (/var/atlassian/bitbucket_home/log/launcher.log) constantly repeats this
>> error:
>>
>> "java.lang.IllegalArgumentException: An invalid domain [.code.doxee.com]
>> was specified for this cookie" .
>>
>
> Is there a stacktrace with this error ?
> It would be good to see which class/method throws this exception.
>
>
>> The error has been present in the log for some time and continues to be.
>>
>> We contacted the support of atlassian, who after an analysis suggested
>> that we ask you about the error in question.
>> Here the link to the discussion, *and all the info, tests and steps we
>> took before contacting you* :
>> https://getsupport.atlassian.com/servicedesk/customer/portal/24/SSP-42041
>>
>> Our Tomcat version is: 8.5.29
>>
>
> Please try with a more recent version of Tomcat, e.g. 8.5.53.
>
>
>>
>> In attachment there is the complete error.
>>
>> We are waiting for an answer that can help you analyze or solve the
>> problem,
>>
>> Thanks a lot,
>> Regards,
>>
>> Luigi
>>
>>
>> [image: signature_1607051054]
>>
>>
>>
>> *Luigi Tagliafierro*
>>
>> *IX Team*
>>
>>
>> doxee.com 
>>
>> find us on:
>>
>> [image: signature_1049012399] [image:
>> signature_145818931] [image:
>> signature_816293899] 
>>
>>
>>
>>
>>
>> Questa email ed ogni eventuale allegato sono confidenziali.
>>
>> Se non siete il destinatario della presente ogni suo utilizzo è vietato.
>>
>> Le chiediamo di segnalare l’accaduto al  mittente e di cancellare il
>> messaggio.
>>
>> Questo messaggio è inviato da Doxee e non ha natura personale, le
>> informazioni contenute possono essere note al mittente o da altri suoi
>> collaboratori.
>>
>>
>>
>> This e-mail and any attachments are confidential.
>>
>> If you are not the intended recipient, you are hereby notified that any
>> use or distribution of this e-mail is strictly prohibited.
>>
>> Please contact the sender and delete this message from your system.
>>
>> We apologize for any inconvenience this may cause.
>>
>> This message is forwarded from Doxee and is not of a personal nature; the
>> information contained herein may be known by the sender and other employees
>> in the company.
>>
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

How to get the number of "keep-alive" connections ?

[Svetlin Zarev]

Hi,

The MBean "Catalina:type=ThreadPool,name="http-nio-8080"" has an attribute
called "keepAliveCount" but instead of the keep-alive connections it
returns the sum of the number of the pollers' selection keys (as a result
it usually reports a low number in the range 0-4 in my test setup). The
closest thing to that count is "connectionCount" from the protocol handler,
but it counts both keep-alive and non keep-alive connections.

So, is "keepAliveCount" just a bad naming/bug, or am I missing something ?
What's the proper way to track the number of "keep-alive" connections ?

Best regards,
Svetlin

Web sockets - issue with proxy handling

[Svetlin Zarev]

Hi all!

Recently I stumbled in a possible bug in WsWebSocketContainer. When
connecting to server, if the authority in the URI does not contain the
remote port, the proxy rejects the connection. In WsWebSocketContainer the
port is determined based on WS/WSS when constructing the InetSocketAddress
for non-proxied communication. But when using proxy, the WS/WSS scheme is
ignored and the CONNECT request looks like:

CONNECT gmail.com HTTP/1.1

So the proxy does not know to which port to open a tunnel. And as a result
connectToServer() fails with DeploymentException due to the proxy rejecting
the connect request.

Patch proposed: https://github.com/apache/tomcat/pull/39
What do you think ?

Best regards,
Svetlin

Re: remove me from tomcat user list

[Svetlin Zarev]

Just send a blank mail to users-unsubscr...@tomcat.apache.org in order to
unsubscribe

Svetlin

2016-08-31 10:01 GMT+03:00 罗茂林 :

> could someone remove me from the tomcat user list？

Re: Increased memory consumption due to url encoding

[Svetlin Zarev]

Thanks Chris,

I've created a pull request on github:
https://github.com/apache/tomcat85/pull/3

> and then look at the diffs manually
It's an almost complete rewrite and has very little in common with the old
encoder

Svetlin

2016-08-30 20:56 GMT+03:00 Christopher Schultz <ch...@christopherschultz.net
>:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Svetlin,
>
> On 8/28/16 12:57 PM, Svetlin Zarev wrote:
> > Hi,
> >
> > Today I had some free time, so I implemented a more (memory and
> > performance wise) efficient URLEncoder [1]  and I'd like to
> > contribute it if there is interest for improvement in that area. My
> > encoder has close to zero allocation rate (unless there is very
> > high concurrency for the encode() operations, but still will be
> > much more memory efficient than the current encoder)  and encodes
> > 2-4 times faster than the current implementation. It is available @
> > [1]. I'm open for reviews, critiques, questions, suggestions, etc.
> >
> > [1] https://github.com/SvetlinZarev/UrlEncoder
>
> Can you post this as a pull request, patch, or similar? Nobody really
> wants to download this code, replace their own local code, and then
> look at the diffs manually. I suspect that's why nobody has looked at
> it, yet.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXxcjVAAoJEBzwKT+lPKRYsCMQAKy/pVLDeSWvcbbHMYwOLwa5
> xhBc3R0ev51qt9rMbkBTQhOZM/beM5u9AcOevFNaQlqr6knxui0R2v7fcM7LKxzU
> w8iRxe+8w1GxA/nPVmUAXU5geL7Z7gnyIf+GBhOlxn8R4cXfkvRBCOP0shZpIXPr
> fF4buxBLGOii3ApiYELdxxM6andEXc8SHd+CoCm9fc3GPMVyR4eFDEg7nNc1Y44t
> FWRBOXNCf0nJRHUDswEqK2ZTlTvd1GFTInLAy9m30uJRzkGDa3ytgfikaBE/c/Je
> ctCtz/g9xUk715YFhm23ZAmGvzi3bWBj9PZ3yTixf646Oa8WPsWWm7vALjRNZcfG
> j8Cy0ugEo1kT9wr1anIdPtr4q22E3k4Gu8SAhEObcO65dFtdZ2kvQ+tJxTceOmjn
> vyplST7kVORuhtWf+rj+L+VgHZsRR54+5C8a9Hf1/TSaI1ztWJbFIYuJr+YgnGw5
> Z264C/rWPr4fd1BRNCwJz9iHoC24IuTJAiNNcVQHrs7xKn16sW4Sq/hM5AE7oJ/5
> RhvpLtZPQmxpqVjvxPallYT0/lMN3CJ26m7A5rf0242MMf9zIsxsnnNUznhh2zNR
> gyJsTHJZ2o4tuwEclimzxrwIbO5RxgIeoTdxTbhsE4775oSQ3VHvE07yDPLlqRAh
> My3/WOXu8myi0WeLoRzE
> =5SJi
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Increased memory consumption due to url encoding

[Svetlin Zarev]

Hi,

Today I had some free time, so I implemented a more (memory and performance
wise) efficient URLEncoder [1]  and I'd like to contribute it if there is
interest for improvement in that area. My encoder has close to zero
allocation rate (unless there is very high concurrency for the encode()
operations, but still will be much more memory efficient than the current
encoder)  and encodes 2-4 times faster than the current implementation. It
is available @ [1]. I'm open for reviews, critiques, questions,
suggestions, etc.

[1] https://github.com/SvetlinZarev/UrlEncoder

Svetlin

Re: Rfc6265CookieProcessor domain validation errors

[Svetlin Zarev]

Thanks Mark, this makes sense.

Best regards,
Svetlin


This isn't a bug. You are misunderstanding the RFC.
>
> Domain attributes are only sent from servers to user agents.
>
> The general rule to keep in mind is:
> "Be lenient in what you accept. Be strict in what you send."
>
> Section 5.2.3 applies to User agents and it is informing them to be
> lenient in what the accept since they can, unambiguously, ignore a
> leading '.' if present on the domain.
>
> Section 4.1.2.3 is referring to the same behaviour.
>
> Tomcat is strict in what it will allow applications to send. The ABNF
> for domain-av does not allow leading '.' so neither does Tomcat.
>
> Tomcat could be lenient here and strip any leading '.' but generally,
> Tomcat does not add code to work around application bugs. It expects
> those bugs to be fixed in the applications. There are exceptions but
> this is one of them and I don't see a compelling case to make it an
> exception.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Rfc6265CookieProcessor domain validation errors

[Svetlin Zarev]

Proposed fix: https://github.com/apache/tomcat85/pull/2

2016-08-25 10:28 GMT+03:00 Svetlin Zarev <svetlin.angelov.za...@gmail.com>:

> Hello!
>
>
>
> The new Rfc6265CookieProcessor fails to validate domains that start with a
> dot. According to rfc6265#5.2.3 [1]:
>
>
>
> If the first character of the attribute-value string is %x2E ("."):
>
>   Let cookie-domain be the attribute-value without the leading %x2E
>
>   (".") character.
>
> Otherwise:
>
>   Let cookie-domain be the entire attribute-value.
>
>
>
> But Rfc6265CookieProcessor throws an IllegalStateException.
>
> Steps to reproduce : https://gist.github.com/anonymous/
> d38cdc359ba4cf436b7e55a2757ae1a7
>
>
>
> What do you think ? Is this a bug in the cookie processor or am I
> misunderstanding the RFC ?
>
>
>
> [1] https://tools.ietf.org/html/rfc6265#page-20
>
>
> Best regards,
>
> Svetlin
>

Rfc6265CookieProcessor minor improvement

[Svetlin Zarev]

Hello,

I'd like to propose the following minor improvement to the cookie
processor: https://github.com/apache/tomcat85/pull/1

Best regards,
Svetlin

Rfc6265CookieProcessor domain validation errors

[Svetlin Zarev]

Hello!



The new Rfc6265CookieProcessor fails to validate domains that start with a
dot. According to rfc6265#5.2.3 [1]:



If the first character of the attribute-value string is %x2E ("."):

  Let cookie-domain be the attribute-value without the leading %x2E

  (".") character.

Otherwise:

  Let cookie-domain be the entire attribute-value.



But Rfc6265CookieProcessor throws an IllegalStateException.

Steps to reproduce :
https://gist.github.com/anonymous/d38cdc359ba4cf436b7e55a2757ae1a7



What do you think ? Is this a bug in the cookie processor or am I
misunderstanding the RFC ?



[1] https://tools.ietf.org/html/rfc6265#page-20


Best regards,

Svetlin

Tomcat backwards incompatible change

[Svetlin Zarev]

Hello!

With [1] and [2] an incompatible change has been introduced to all current
versions of Tomcat. The issue is that when calling
requestDispatcher.forward(), the target servlet receives the encoded URL
instead of the one used to obtain the dispatcher. This breaks all
applications depending on the previous Tomcat behavior.

[1]
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java?r1=1741019=1741018=1741019
[2]
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java?r1=1741024=1741023=1741024

Kind regards,
Svetlin

Tomcat does not log exceptions thrown by the valve chain

[Svetlin Zarev]

Hello,



I have a custom authenticator valve which failed with an exception  that
never got logged by tomcat.

After a little bit of digging in tomcat’s source it turned out that there
is no valve responsible for logging

exceptions thrown by valves later in the chain. The closest error handling
mechanism to what I’m looking

for, is StandardHostValve’s try-catch around the valve chain, which
unfortunately logs the exceptions

only if someone has called setError() on the  response.  To be more clear –
StandardHostValve either

sets the RequestDispatcher.ERROR_EXCEPTION or logs the exception.



That logic was introduced with the fix for
https://bz.apache.org/bugzilla/show_bug.cgi?id=54123 with

(git) commit id: *cf4fae533cb303c97031b68ec652d6624207df21 *

And was later modified a bit with the fix for
https://bz.apache.org/bugzilla/show_bug.cgi?id=57252 with

(git) commit id: *9807122abe9b95e1766d992314e661d9f9ed3634 *



What do you think about always logging the caught throwable  (the rest of
the logic remains unchanged) ?



diff --git a/java/org/apache/catalina/core/StandardHostValve.java
b/java/org/apache/catalina/core/StandardHostValve.java

index 48683f5..17f2dc5 100644

--- a/java/org/apache/catalina/core/StandardHostValve.java

+++ b/java/org/apache/catalina/core/StandardHostValve.java

@@ -176,13 +176,12 @@ final class StandardHostValve extends ValveBase {

 }

 } catch (Throwable t) {

 ExceptionUtils.handleThrowable(t);

+container.getLogger().error("Exception Processing " +

+request.getRequestURI(), t);

+

 // If a new error occurred while trying to report a
previous

-// error simply log the new error and allow the original
error

-// to be reported.

-if (response.isErrorReportRequired()) {

-container.getLogger().error("Exception Processing " +

-request.getRequestURI(), t);

-} else {

+// error allow the original error to be reported.

+if (!response.isErrorReportRequired()) {

 request.setAttribute(RequestDispatcher.ERROR_EXCEPTION,
t);

 throwable(request, response, t);

 }



Best regards,

Svetlin