Thanks ! now its clear for me, ones more want to repeat my position — sending
exceptions to the client side looks like bad design, because exceptions its
about unhealthy system recognition from administrator side, not from client of
course, but looks like for now it`s more informative than exi
>
> Alexey.
>
> This option should be on the server side, so server administrator can
> disable stack trace for all clients.
> Correct?
>
Yes, correct.
Alexey.
This option should be on the server side, so server administrator can disable
stack trace for all clients.
Correct?
> 25 авг. 2020 г., в 12:47, Alexey Goncharuk
> написал(а):
>
> Zhenya,
>
> Stacktraces are considered to be able to expose sensitive information about
> code, see [1].
Zhenya,
Stacktraces are considered to be able to expose sensitive information about
code, see [1]. So as previously, I agree with Pavel that we should have an
option to disable this behavior.
[1]
https://wiki.sei.cmu.edu/confluence/display/java/ERR01-J.+Do+not+allow+exceptions+to+expose+sensitive
.@apache.org >
> wrote:
> >
> >> Link to the original discussion:
> >>
> >>
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Exception-handling-in-thin-client-should-we-pass-stack-traces-to-the-client-td22392.html
> >>
> >>
org > wrote:
>
>> Link to the original discussion:
>>
>>
>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/Exception-handling-in-thin-client-should-we-pass-stack-traces-to-the-client-td22392.html
>>
>> On Thu, Aug 20, 2020 at 4:46 PM Zhen
Pavel Tupitsyn wrote:
> Link to the original discussion:
>
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Exception-handling-in-thin-client-should-we-pass-stack-traces-to-the-client-td22392.html
>
> On Thu, Aug 20, 2020 at 4:46 PM Zhenya Stanilovsky
> wrote
Link to the original discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/Exception-handling-in-thin-client-should-we-pass-stack-traces-to-the-client-td22392.html
On Thu, Aug 20, 2020 at 4:46 PM Zhenya Stanilovsky
wrote:
>
> I want to resurrect this discussion, i don`t unde
I want to resurrect this discussion, i don`t understand what sensitive
information you are talking about ?
Can you show some examples or something else ? I never listen that thread dumps
belong to sensitive info.
I believe that one linear error can`t help user to recognize problem and logs
from
Fully agree. As Alex mentioned web servers support dev and prod modes. We
need to do the same and default mode should be dev with warning on startup
and ability to change in runtime.
--Yakov
Thanks, folks!
Excellent catch - we should not decide whether to allow it or not, but
rather make it configurable.
On Tue, Sep 19, 2017 at 10:43 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> I think the protocol should allow both, and the behavior should be either
> configurable or
Hi Vladimir,
All of these arguments are relevant. I suggest to provide full stacktrace
at least by server option. This is also common practice on web servers.
Sincerely,
Dmitriy Pavlov
вт, 19 сент. 2017 г. в 10:20, Vladimir Ozerov :
> Igniters,
>
> We had a discussion about how to propagate err
I think the protocol should allow both, and the behavior should be either
configurable or enabled via a system property. Every web server known to me
allows exposing this information for debugging purposes.
2017-09-19 10:20 GMT+03:00 Vladimir Ozerov :
> Igniters,
>
> We had a discussion about how
Igniters,
We had a discussion about how to propagate error information from cluster
nodes to the client. My opinion is that we should pass a kind of vendor
code plus optional error message, if vendor code is not very specific.
Alternative idea is to pass the whole stack trace as well. I agree tha
14 matches
Mail list logo
