Re: Reg CVE-2017-5664

[Durga Srinivasu Karuturi]

Thanks mark.

Checked Error Servlet, handled doGet() and doPost() only. doPost()
internally calling doGet().
Yes for PUT/DELTE we are getting 405.

Thanks,
Durga Srinivasu

On Fri, Jun 23, 2017 at 4:38 AM, Mark Thomas <ma...@apache.org> wrote:

> On 22/06/17 16:46, Durga Srinivasu Karuturi wrote:
> > Hi,
> >
> > We are using tomcat 8.5.14.
> >
> > As this CVE-2017-5664
> > <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5664> is
> applicable
> > for current tomcat version, we are trying to evaluate whethere this CVE
> is
> > applicable to our web application or not.
> >
> >
> > We have couple of JSP error pages. Tested those all are severed as GET.
>
> No issue with the JSPs as long as they don't check the HTTP method and
> take different actions depending on what it is.
>
> > Also we have custom error Servlet handler configured and in that also, we
> > do handle it as GET only.
>
> Might be worth checking how those servlets respond to non-GET requests.
> If you have only implemented doGet() your users could see a 405 response
> rather than the error page. That should be OK from a security point of
> view.
>
> > There are no static error files configured in our web application.
>
> Good. That removes probably the biggest risk which is the default servlet.
>
> > With these can be take this CVE is not application to our web application
> > with 8.5.14 tomcat?
>
> From the information you have provided, you look to be OK but it is
> worth checking the few things I pointed out above.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Reg CVE-2017-5664

[Durga Srinivasu Karuturi]

No, we are using RHEL with embed tomcat running inside java.

Thanks,
Durga Srinivasu

On Thu, Jun 22, 2017 at 10:03 PM, Emmanuel Bourg <ebo...@apache.org> wrote:

> Le 22/06/2017 à 17:46, Durga Srinivasu Karuturi a écrit :
>
> > We are using tomcat 8.5.14.
>
> From Debian 9? If so this has been patched today:
>
>   https://www.debian.org/security/2017/dsa-3891
>
> Emmanuel Bourg
>

Reg CVE-2017-5664

[Durga Srinivasu Karuturi]

Hi,

We are using tomcat 8.5.14.

As this CVE-2017-5664
 is applicable
for current tomcat version, we are trying to evaluate whethere this CVE is
applicable to our web application or not.


We have couple of JSP error pages. Tested those all are severed as GET.

Also we have custom error Servlet handler configured and in that also, we
do handle it as GET only.

There are no static error files configured in our web application.

With these can be take this CVE is not application to our web application
with 8.5.14 tomcat?

Please suggest.

Thanks,
Durga Srinivasu

Re: Latest JDT Compiler Issues.

[Durga Srinivasu Karuturi]

Thanks mark for quick reply.

Raised below issue for tracking purpose:

https://bz.apache.org/bugzilla/show_bug.cgi?id=61057

Meanwhile we continue to use ecj-4.5.1 with latest tomcat 8.5.14.

Thanks,
Durga Srinivasu

On Sun, Apr 30, 2017 at 11:52 PM, Mark Thomas <ma...@apache.org> wrote:

> On 30/04/17 18:36, Durga Srinivasu Karuturi wrote:
> > Hi,
> >
> > We have tried migrating tomcat from 8.5.11 --> 8.5.14 for latest security
> > fixes and found our jasaperreports functionality is broken.
>
> 
>
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=495598
> >
> > I have tried 4.5.1 (from old tomcat 8.5.11) and 4.6.2 (from
> > http://central.maven.org/maven2/org/eclipse/scout/sdk/
> deps/ecj/4.6.2/ecj-4.6.2.jar)
> > it works fine.
> >
> > Can we consider to change JDT to 4.6.2 in upcoming releases?
>
> Sure. Please open a Bugzilla issue to track this.
>
> > Mean while, is it okay to use old JDT 4.5.1 (ecj-4.5.1) with latest
> tomcat
> > 8.5.14?
>
> Yes, that should be fine.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Latest JDT Compiler Issues.

[Durga Srinivasu Karuturi]

Hi,

We have tried migrating tomcat from 8.5.11 --> 8.5.14 for latest security
fixes and found our jasaperreports functionality is broken.

Reports compilation is failing with unresolved type errors even though all
related jars are in classpath

1. java.util.ResourceBundle cannot be resolved to a type
value = ((java.util.ResourceBundle)
parameter_REPORT_RESOURCE_BUNDLE.getValue()); //$JR_EXPR_ID=34$
  <-->
2. net.sf.jasperreports.engine.JRDataSource cannot be resolved to a type
value = ((net.sf.jasperreports.engine.
JRDataSource)parameter_DS_controllers_by_model609.getValue());
//$JR_EXPR_ID=37$
  <-->
3. net.sf.jasperreports.engine.JasperReport cannot be resolved to a type
value = ((net.sf.jasperreports.engine.
JasperReport)parameter_SR_controllers_by_model609.getValue());
//$JR_EXPR_ID=38$
  <-->
4. java.util.ResourceBundle cannot be resolved to a type
value = ((java.util.ResourceBundle)
parameter_REPORT_RESOURCE_BUNDLE.getValue()); //$JR_EXPR_ID=40$
  <-->
Debugged further and found this is because of 4.6.1 JDT compiler change
from 8.5.12. This is a regression issue from JDT 4.6.1

https://bugs.eclipse.org/bugs/show_bug.cgi?id=495598

I have tried 4.5.1 (from old tomcat 8.5.11) and 4.6.2 (from
http://central.maven.org/maven2/org/eclipse/scout/sdk/deps/ecj/4.6.2/ecj-4.6.2.jar)
it works fine.

Can we consider to change JDT to 4.6.2 in upcoming releases?

Mean while, is it okay to use old JDT 4.5.1 (ecj-4.5.1) with latest tomcat
8.5.14?

Thanks,
Durga Srinivasu

Reg Sendfile Feature

[Durga Srinivasu Karuturi]

Hi,

We are trying to analyze two of the below CVEs related to tomcat sendfile
feature.

CVE-2017-5647 (Production tomcat 8.0.26)
CVE-2017-5651(Current tomcat 8.5.12)

We are enabling compression with NIO connector.

As per docs, connector level by default sendfile is enabled and sendfile
takes precedence over compression.

We are not setting any request attribute "org.apache.tomcat.sendfile.support"
to enable this support also.

With this can we assume sendfile will not be used and these two CVEs are
not application for us.

Or Do we need to disable connector level to completed turnoff sendfile?

Please clarify.

Thanks,
Durga Srinivasu

Re: Logging TLS Session Failures

[Durga Srinivasu Karuturi]

Thanks,

Will explore JSSE options.

On Thu, Mar 9, 2017 at 7:18 PM, Jammy Chen <jamm...@gmail.com> wrote:

> If you are using JSSE which you mentioned in earlier post, you probably can
> only enable debug for all or specially one
> -Djavax.net.debug=ssl:record or -Djavax.net.debug=ssl:handshake - but it
> will log all sessions
>
> You could try to register a customized SSL socket factory in JSSE, you may
> extend the default sun impl to overwrite the method, catch the exception
> and log the failure, and throw it.
>
> 2017-03-09 20:04 GMT+08:00 Durga Srinivasu Karuturi <
> durgasriniv...@gmail.com>:
>
> > Our application meaning on RHEL machine within JVM with embedded tomcat
> > (with single web-app)
> >
> > Okay, tomcat may not have this information on handshake failures.
> >
> > I need to see little higher level for capturing these failures.
> >
> > Thanks for answers so far.
> >
> > Thanks,
> > Durga Srinivasu
> >
> > On Thu, Mar 9, 2017 at 3:44 PM, André Warnier (tomcat) <a...@ice-sa.com>
> > wrote:
> >
> > > On 09.03.2017 09:34, Durga Srinivasu Karuturi wrote:
> > >
> > >> This is one of the requirement from FIPS/CC certification.
> > >>
> > >> Thanks,
> > >> Durga Srinivasu
> > >>
> > >>
> > > Durga,
> > >
> > > I believe that in your original post, you said :
> > > "We have a requirement in our application to log all TLS session
> > failures."
> > >
> > > You should probably have another look a the precise requirements, and
> the
> > > exact definition of "our application".
> > > Because it may be that the requirements are wrong, as far as you are
> > > concerned.
> > >
> > > It depends on what is included in "our application".
> > > In the java servlet container (like Tomcat) terminology, an
> "application"
> > > is a webapp.
> > > A webapp runs inside a servlet container.
> > > The servlet container (here Tomcat) runs inside a java JVM.
> > > The java JVM runs inside an OS.
> > > The OS runs inside a host.
> > >
> > > In that hierarchy, a webapp only sees a request, when the servlet
> > > container has received this request on one of its ports, and
> "delegates"
> > > the request to the webapp.
> > > By that time, the webapp does not even know through which interface the
> > > request came in, nor if that interface required HTTP, HTTPS or whatever
> > > other communications protocol.
> > > And if a TLS connection from a browser failed, the webapp is not even
> > > called, so it does not know anything about it.
> > > Of course the webapp cannot log a failure, if it is never called when
> > that
> > > failure happens.
> > >
> > > To move one level up : if a TLS connection from a browser fails, Tomcat
> > > probably never even sees that (because the connection never reaches
> > > Tomcat). So Tomcat cannot log this failure either. Tomcat is just
> telling
> > > some underlying layer of software (in the JVM, in the OS, or in some
> > > external library), what kind of connections to accept. But it does  not
> > > manage these connections, it just "gets" a connection when it succeeds.
> > >
> > > So if you (your team, your company) is responsible for providing the
> > whole
> > > service, including the host, the OS, the JVM, the servlet container,
> and
> > > the webapp inside it, then the requirement may make sense. And then you
> > > have to look for the component, at the right level, which can provide
> > that
> > > information. (But it is not the webapp, and it is not Tomcat).
> > >
> > > At the other extreme, if you are providing only the web application,
> then
> > > the requirement does not make sense /for you/, because it is
> impossible.
> > > It is not that it does not make sense in general, but "as part of the
> > > webapp" it does not make sense.
> > >
> > > And that is what Christopher is also telling you (in a lot less words).
> > >
> > >
> > >
> > > On Wed, Mar 8, 2017 at 11:03 PM, Christopher Schultz <
> > >> ch...@christopherschultz.net> wrote:
> > >>
> > >> -BEGIN PGP SIGNED MESSAGE-
> > >>> Hash: SHA256
> > >>>
> > >>> Durga,
> > >>>
> > >>>

Re: Logging TLS Session Failures

[Durga Srinivasu Karuturi]

Our application meaning on RHEL machine within JVM with embedded tomcat
(with single web-app)

Okay, tomcat may not have this information on handshake failures.

I need to see little higher level for capturing these failures.

Thanks for answers so far.

Thanks,
Durga Srinivasu

On Thu, Mar 9, 2017 at 3:44 PM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:

> On 09.03.2017 09:34, Durga Srinivasu Karuturi wrote:
>
>> This is one of the requirement from FIPS/CC certification.
>>
>> Thanks,
>> Durga Srinivasu
>>
>>
> Durga,
>
> I believe that in your original post, you said :
> "We have a requirement in our application to log all TLS session failures."
>
> You should probably have another look a the precise requirements, and the
> exact definition of "our application".
> Because it may be that the requirements are wrong, as far as you are
> concerned.
>
> It depends on what is included in "our application".
> In the java servlet container (like Tomcat) terminology, an "application"
> is a webapp.
> A webapp runs inside a servlet container.
> The servlet container (here Tomcat) runs inside a java JVM.
> The java JVM runs inside an OS.
> The OS runs inside a host.
>
> In that hierarchy, a webapp only sees a request, when the servlet
> container has received this request on one of its ports, and "delegates"
> the request to the webapp.
> By that time, the webapp does not even know through which interface the
> request came in, nor if that interface required HTTP, HTTPS or whatever
> other communications protocol.
> And if a TLS connection from a browser failed, the webapp is not even
> called, so it does not know anything about it.
> Of course the webapp cannot log a failure, if it is never called when that
> failure happens.
>
> To move one level up : if a TLS connection from a browser fails, Tomcat
> probably never even sees that (because the connection never reaches
> Tomcat). So Tomcat cannot log this failure either. Tomcat is just telling
> some underlying layer of software (in the JVM, in the OS, or in some
> external library), what kind of connections to accept. But it does  not
> manage these connections, it just "gets" a connection when it succeeds.
>
> So if you (your team, your company) is responsible for providing the whole
> service, including the host, the OS, the JVM, the servlet container, and
> the webapp inside it, then the requirement may make sense. And then you
> have to look for the component, at the right level, which can provide that
> information. (But it is not the webapp, and it is not Tomcat).
>
> At the other extreme, if you are providing only the web application, then
> the requirement does not make sense /for you/, because it is impossible.
> It is not that it does not make sense in general, but "as part of the
> webapp" it does not make sense.
>
> And that is what Christopher is also telling you (in a lot less words).
>
>
>
> On Wed, Mar 8, 2017 at 11:03 PM, Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> Durga,
>>>
>>> On 3/8/17 10:02 AM, Durga Srinivasu Karuturi wrote:
>>>
>>>> We are using JSSE only not APR. Looking for handshake failures.
>>>>
>>>> Yes, using JSSE SSL debug, we are able to get all handshake
>>>> (-Djavax.net.debug=ssl:handshake) logs including success cases.
>>>> These are still quite bit expense logs and meant for debug
>>>> purposes. As you said it might impact performance that's the
>>>> reason, trying for any other optimal solution here.
>>>>
>>>
>>> I know of no way to be notified about handshake failures on the server
>>> side. You may not be able to fulfill this requirement if using Java
>>> for your crypto.
>>>
>>> Honestly, I'm not sure why you care about failed TLS handshakes. Are
>>> you trying to implement a NIDS in your application? This is
>>> better-handled by a network component specifically-designed for this
>>> kind of thing.
>>>
>>> - -chris
>>> -BEGIN PGP SIGNATURE-
>>> Comment: GPGTools - http://gpgtools.org
>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>
>>> iQIcBAEBCAAGBQJYwEBVAAoJEBzwKT+lPKRYHzkP/1O2jPMu6Z9MBdnCF6LD7FQl
>>> LMWA6jmO2YjmZFPtJykyUXHuL3beBk/+5cPV275ZApp1brJmmqnxR68P4ZuedOwY
>>> pX+dLiBTvmLYmsFoYxxfdvpl44UICwvq6qx/4VsSS0okrz9JYQtmO9d2glYG6bDD
>

Re: Logging TLS Session Failures

[Durga Srinivasu Karuturi]

This is one of the requirement from FIPS/CC certification.

Thanks,
Durga Srinivasu

On Wed, Mar 8, 2017 at 11:03 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Durga,
>
> On 3/8/17 10:02 AM, Durga Srinivasu Karuturi wrote:
> > We are using JSSE only not APR. Looking for handshake failures.
> >
> > Yes, using JSSE SSL debug, we are able to get all handshake
> > (-Djavax.net.debug=ssl:handshake) logs including success cases.
> > These are still quite bit expense logs and meant for debug
> > purposes. As you said it might impact performance that's the
> > reason, trying for any other optimal solution here.
>
> I know of no way to be notified about handshake failures on the server
> side. You may not be able to fulfill this requirement if using Java
> for your crypto.
>
> Honestly, I'm not sure why you care about failed TLS handshakes. Are
> you trying to implement a NIDS in your application? This is
> better-handled by a network component specifically-designed for this
> kind of thing.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYwEBVAAoJEBzwKT+lPKRYHzkP/1O2jPMu6Z9MBdnCF6LD7FQl
> LMWA6jmO2YjmZFPtJykyUXHuL3beBk/+5cPV275ZApp1brJmmqnxR68P4ZuedOwY
> pX+dLiBTvmLYmsFoYxxfdvpl44UICwvq6qx/4VsSS0okrz9JYQtmO9d2glYG6bDD
> onLmqYoivB2N+18jXoT7PAzBZcAhHFbIFPIox4VXjs9za/WQ4Oc+BUecUKpOCc0i
> yvMz1I9Bo5E+tCMkTsTpbtq/Sk5lF7JozOycda3OVmLpVTf7Xz07luOF0ZaJAY0t
> VMHvNEOuph9dJxkS6mXlPnqqQwf3Prlwhx/zjWm6HT9prGBMraVb9laq44qMMUcg
> rDSSgfxZDiSJKDw7bCA3+o3KQfqIqbkLH9nQ2WICS2YAd9jn5tqy5Faf/H7Dd71D
> mYOdVxXPk5XJPuVOWaK9dVQOEppZ8JWjxxKaofFxFXmQpaiVbSP5FLduRrkvKgJc
> e9necMTzyxs9RwvpJjQtf10blDc51bL3Y+KjbTgJoPTqAIm8kUgI9VOE5NUs5eip
> 1MO9ub52ojavC10B+lU3OGggwHp068ozkM491stTZialCaTCmbo7LPZtKzIz0g4j
> q3JgDS4Y4LVPOoLPjUSfcbzTsxnS2V/SkLhOwQpnvw4lTLrotq5CGPJDQD5ix67j
> 2WbMcngOqAvk16kPb5u+
> =F7yo
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Logging TLS Session Failures

[Durga Srinivasu Karuturi]

Chris,

We are using JSSE only not APR. Looking for handshake failures.

Yes, using JSSE SSL debug, we are able to get all handshake
(-Djavax.net.debug=ssl:handshake) logs including success cases. These are
still quite bit expense logs and meant for debug purposes. As you said it
might impact performance that's the reason, trying for any other optimal
solution here.


Thanks,
Durga Srinivasu

On Wed, Mar 8, 2017 at 8:10 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Durga,
>
> On 3/8/17 9:29 AM, Durga Srinivasu Karuturi wrote:
> > We have a requirement in our application to log all TLS session
> > failures.
>
> Specifically, what kind of failures? Failed handshakes? Initial or
> re-negotiation? Are you using JSSE or APR? If JSSE, are you using the
> OpenSSL crypto-backend?
>
> > We are using Tomcat 8.5.11 using JSSE for SSL layer. Is there any
> > way to configure tomcat to log/trace any TLS Failure on tomcat
> > sessions?
>
> Not at the moment. If you are using JSSE with the Oracle crypto
> backend, you can put it into debug mode, but you don't want to do
> that; it will produce so much output it will measurably slow-down your
> server.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYwBfWAAoJEBzwKT+lPKRYPDMP/06EccSRlV9KGNtQ2167Plsw
> PNefVfp4qcSHlsT8xBe2pWDU52ybLqOugBKGtTxa/ZGHDo1aMJCR+HZJqNspujdl
> Qe/7GVFKlzu6d8ucBJ/VgjM/sU+dLQnYW7sLJpfiM7gtOD3zcRYH1BN7iTW1Ij6e
> JYFrqvP6TJpdHtJgQ9n8AXB/+iUzqF6sigJPYFe6HNM4oAiuU6M8AzhNwtNM2AUN
> fnE2OyB+0FNcnwizLqhZ9+RJZeMIbb8wsyUJiOGkqyTBFcYrsPx5VR6A29+u+3R1
> FKES8jgzDAqlztdG2kZK8EmUrJokRT9aDoDKYbuSWW/+QujDDpl76pLdSaTR/eVB
> RuJSRwkyV3VA68Wg6FBGFNNCmV/1t2Yii3dLxa1aLph6TipIyEo16nyDr7yf5HPZ
> hKyfoeyIMVvreN0ldjwNlsKvlHHDheun5l02/h7hE934UYb+9KyfY1vhWuzfNcKu
> QgG8oExdi91GfjAR9vApTuVm5fAra07oqNzlXhFrx3dbYWrJamTL6uymlvxoHhhL
> KkVz6F68sMR0AqDV2+tgcKOxV7GWl+kQueMo7csBZ54kNaNN/Qcw2tRyG4iz0mNk
> ihRG5REvbqTGfN+TQzoeYLdysdU7n1R/tfxb4dHeqP6x8FMOTwz/yRdYywUsX+9e
> 83XGxnDX3Ps0mW9xA8Ab
> =H9l5
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Logging TLS Session Failures

[Durga Srinivasu Karuturi]

Hi,

We have a requirement in our application to log all TLS session failures.

We are using Tomcat 8.5.11 using JSSE for SSL layer. Is there any way to
configure tomcat to log/trace any TLS Failure on tomcat sessions?

Thanks,
Durga Srinivasu

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

[Durga Srinivasu Karuturi]

Mark,

Thanks for the fix!

We will use 8.5.10 once it is available.

Thanks,
Durga Srinivasu

On Sat, Dec 24, 2016 at 11:33 PM, Mark Thomas <ma...@apache.org> wrote:

> On 24/12/2016 14:51, Durga Srinivasu Karuturi wrote:
> > Mark,
> >
> > Thanks for the update!
>
> Fixed for 9.0.0.M16 onwards and 8.5.10 onwards. Releases of these are
> likely in the first few weeks of 2017.
>
> The root cause was Tomact agreeing the new HTTP/2 setting but not
> updating the HPACK encoder so the encoder carried on using the old value.
>
> Mark
>
>
> >
> > Thanks,
> > Durga Srinivasu
> >
> > On Sat, Dec 24, 2016 at 6:47 PM, Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 22/12/2016 12:58, Mark Thomas wrote:
> >>> On 22 December 2016 10:16:18 GMT+00:00, Durga Srinivasu Karuturi <
> >> durgasriniv...@gmail.com> wrote:
> >>>> Hi,
> >>>>
> >>>> Shall i raise a defect?
> >>>
> >>> Patience. Give the community a chance to look at it first. Given the
> >> time of year, that might take longer than usual.
> >>
> >> I can confirm I can repeat the problem you are describing.
> >>
> >> Tomcat not sending an HPACK dynamic table size update is certainly a
> >> possibility.
> >>
> >> I'll look into the root cause next.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Mark
> >>>
> >>>
> >>>>
> >>>> Thanks,
> >>>> Durga Srinivasu
> >>>>
> >>>> On Wed, Dec 21, 2016 at 2:56 PM, Durga Srinivasu Karuturi <
> >>>> durgasriniv...@gmail.com> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> We are stuck with this issue.
> >>>>>
> >>>>> Is this locally reproducible with sample web-app?
> >>>>>
> >>>>> Thanks,
> >>>>> Durga Srinvasu
> >>>>>
> >>>>>
> >>>>> On Tue, Dec 20, 2016 at 11:26 AM, Durga Srinivasu Karuturi <
> >>>>> durgasriniv...@gmail.com> wrote:
> >>>>>
> >>>>>> Its ~5MB file (ROOT app tar bundle).
> >>>>>>
> >>>>>> I hope the information, which i have shared so far is useful enough
> >>>> to
> >>>>>> reproduce the problem locally.
> >>>>>>
> >>>>>> Please let me know if i missed any other information.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Durga Srinivasu
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Dec 20, 2016 at 7:42 AM, Sreeraj V P <sree...@entesos.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> yes.. started download.. hadnt waited to complete.
> >>>>>>>
> >>>>>>> Sent from BlueMail ​
> >>>>>>>
> >>>>>>> On 19 Dec 2016, 3:27 p.m., at 3:27 p.m., Durga Srinivasu Karuturi <
> >>>>>>> durgasriniv...@gmail.com> wrote:
> >>>>>>>> Mark,
> >>>>>>>>
> >>>>>>>> Looks like tar/zip attachments are getting removed.
> >>>>>>>>
> >>>>>>>> Uploaded same in google drive now.
> >>>>>>>>
> >>>>>>>> Please let me know if you can access the same or not.
> >>>>>>>>
> >>>>>>>> https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Durga Srinivasu
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
> >>>>>>>> durgasriniv...@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> Mark,
> >>>>>>>>>
> >>>>>>>>> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle.
> >>>> Just
> >>>>>>>> changed
> >>>>>>>>> index.jsp and added lib [mostly DOJO] folder content to
> >>>> reproduce.
> >>>>>>>>>
> >>>>

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

[Durga Srinivasu Karuturi]

Mark,

Thanks for the update!

Thanks,
Durga Srinivasu

On Sat, Dec 24, 2016 at 6:47 PM, Mark Thomas <ma...@apache.org> wrote:

> On 22/12/2016 12:58, Mark Thomas wrote:
> > On 22 December 2016 10:16:18 GMT+00:00, Durga Srinivasu Karuturi <
> durgasriniv...@gmail.com> wrote:
> >> Hi,
> >>
> >> Shall i raise a defect?
> >
> > Patience. Give the community a chance to look at it first. Given the
> time of year, that might take longer than usual.
>
> I can confirm I can repeat the problem you are describing.
>
> Tomcat not sending an HPACK dynamic table size update is certainly a
> possibility.
>
> I'll look into the root cause next.
>
> Mark
>
>
> >
> > Mark
> >
> >
> >>
> >> Thanks,
> >> Durga Srinivasu
> >>
> >> On Wed, Dec 21, 2016 at 2:56 PM, Durga Srinivasu Karuturi <
> >> durgasriniv...@gmail.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> We are stuck with this issue.
> >>>
> >>> Is this locally reproducible with sample web-app?
> >>>
> >>> Thanks,
> >>> Durga Srinvasu
> >>>
> >>>
> >>> On Tue, Dec 20, 2016 at 11:26 AM, Durga Srinivasu Karuturi <
> >>> durgasriniv...@gmail.com> wrote:
> >>>
> >>>> Its ~5MB file (ROOT app tar bundle).
> >>>>
> >>>> I hope the information, which i have shared so far is useful enough
> >> to
> >>>> reproduce the problem locally.
> >>>>
> >>>> Please let me know if i missed any other information.
> >>>>
> >>>> Thanks,
> >>>> Durga Srinivasu
> >>>>
> >>>>
> >>>> On Tue, Dec 20, 2016 at 7:42 AM, Sreeraj V P <sree...@entesos.com>
> >> wrote:
> >>>>
> >>>>> yes.. started download.. hadnt waited to complete.
> >>>>>
> >>>>> Sent from BlueMail ​
> >>>>>
> >>>>> On 19 Dec 2016, 3:27 p.m., at 3:27 p.m., Durga Srinivasu Karuturi <
> >>>>> durgasriniv...@gmail.com> wrote:
> >>>>>> Mark,
> >>>>>>
> >>>>>> Looks like tar/zip attachments are getting removed.
> >>>>>>
> >>>>>> Uploaded same in google drive now.
> >>>>>>
> >>>>>> Please let me know if you can access the same or not.
> >>>>>>
> >>>>>> https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Durga Srinivasu
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
> >>>>>> durgasriniv...@gmail.com> wrote:
> >>>>>>
> >>>>>>> Mark,
> >>>>>>>
> >>>>>>> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle.
> >> Just
> >>>>>> changed
> >>>>>>> index.jsp and added lib [mostly DOJO] folder content to
> >> reproduce.
> >>>>>>>
> >>>>>>> If we deploy this in latest 8.5.9 with http2 enabled in chrome
> >> we are
> >>>>>>> seeing the SPDY compression errors
> >>>>>>>
> >>>>>>> Please let me know if this helps.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Durga Srinivasu
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas <ma...@apache.org>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
> >>>>>>>>> Do i need to post in any other forum?
> >>>>>>>>
> >>>>>>>> No, you are in the right place.
> >>>>>>>>
> >>>>>>>> You mentioned the issue was reproducible with the Dojo
> >> libraries. If
> >>>>>> you
> >>>>>>>> can provide the simplest possible set of steps to recreate this
> >>>>>> issue
> &

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

[Durga Srinivasu Karuturi]

Hi,

Shall i raise a defect?

Thanks,
Durga Srinivasu

On Wed, Dec 21, 2016 at 2:56 PM, Durga Srinivasu Karuturi <
durgasriniv...@gmail.com> wrote:

> Hi,
>
> We are stuck with this issue.
>
> Is this locally reproducible with sample web-app?
>
> Thanks,
> Durga Srinvasu
>
>
> On Tue, Dec 20, 2016 at 11:26 AM, Durga Srinivasu Karuturi <
> durgasriniv...@gmail.com> wrote:
>
>> Its ~5MB file (ROOT app tar bundle).
>>
>> I hope the information, which i have shared so far is useful enough to
>> reproduce the problem locally.
>>
>> Please let me know if i missed any other information.
>>
>> Thanks,
>> Durga Srinivasu
>>
>>
>> On Tue, Dec 20, 2016 at 7:42 AM, Sreeraj V P <sree...@entesos.com> wrote:
>>
>>> yes.. started download.. hadnt waited to complete.
>>>
>>> Sent from BlueMail ​
>>>
>>> On 19 Dec 2016, 3:27 p.m., at 3:27 p.m., Durga Srinivasu Karuturi <
>>> durgasriniv...@gmail.com> wrote:
>>> >Mark,
>>> >
>>> >Looks like tar/zip attachments are getting removed.
>>> >
>>> >Uploaded same in google drive now.
>>> >
>>> >Please let me know if you can access the same or not.
>>> >
>>> >https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8
>>> >
>>> >Thanks,
>>> >Durga Srinivasu
>>> >
>>> >
>>> >On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
>>> >durgasriniv...@gmail.com> wrote:
>>> >
>>> >> Mark,
>>> >>
>>> >> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle. Just
>>> >changed
>>> >> index.jsp and added lib [mostly DOJO] folder content to reproduce.
>>> >>
>>> >> If we deploy this in latest 8.5.9 with http2 enabled in chrome we are
>>> >> seeing the SPDY compression errors
>>> >>
>>> >> Please let me know if this helps.
>>> >>
>>> >> Thanks,
>>> >> Durga Srinivasu
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas <ma...@apache.org>
>>> >wrote:
>>> >>
>>> >>> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
>>> >>> > Do i need to post in any other forum?
>>> >>>
>>> >>> No, you are in the right place.
>>> >>>
>>> >>> You mentioned the issue was reproducible with the Dojo libraries. If
>>> >you
>>> >>> can provide the simplest possible set of steps to recreate this
>>> >issue
>>> >>> from a clean Tomcat 8.5.9 install that would be a big help.
>>> >>>
>>> >>> Mark
>>> >>>
>>> >>> >
>>> >>> > Thanks,
>>> >>> > Durga Srinivasu
>>> >>> >
>>> >>> > On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
>>> >>> > <durgasriniv...@gmail.com <mailto:durgasriniv...@gmail.com>>
>>> >wrote:
>>> >>> >
>>> >>> > Hi,
>>> >>> >
>>> >>> > Any pointers please?
>>> >>> >
>>> >>> > Thanks,
>>> >>> > Durga Srinivasu
>>> >>> >
>>> >>> > On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi
>>> >>> > <durgasriniv...@gmail.com <mailto:durgasriniv...@gmail.com>>
>>> >wrote:
>>> >>> >
>>> >>> > Hi,
>>> >>> >
>>> >>> > Recent chrome  [Mac - Sierra : Version  55.0.2883.87
>>> >(64-bit) ]
>>> >>> we are seeing issues in http2 sites.
>>> >>> >
>>> >>> >
>>> >>> > Initially we have seen problem with http2 table header
>>> >size
>>> >>> limit error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9
>>> >where
>>> >>> tomcat has increased the header limit from 16K to 64K.
>>> >>> >
>>> >>> >
>>> >>> > Now with latest tomcat 8.5.9 we are seeing
>>> >>> ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
>>> >>&g

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

[Durga Srinivasu Karuturi]

Hi,

We are stuck with this issue.

Is this locally reproducible with sample web-app?

Thanks,
Durga Srinvasu


On Tue, Dec 20, 2016 at 11:26 AM, Durga Srinivasu Karuturi <
durgasriniv...@gmail.com> wrote:

> Its ~5MB file (ROOT app tar bundle).
>
> I hope the information, which i have shared so far is useful enough to
> reproduce the problem locally.
>
> Please let me know if i missed any other information.
>
> Thanks,
> Durga Srinivasu
>
>
> On Tue, Dec 20, 2016 at 7:42 AM, Sreeraj V P <sree...@entesos.com> wrote:
>
>> yes.. started download.. hadnt waited to complete.
>>
>> Sent from BlueMail ​
>>
>> On 19 Dec 2016, 3:27 p.m., at 3:27 p.m., Durga Srinivasu Karuturi <
>> durgasriniv...@gmail.com> wrote:
>> >Mark,
>> >
>> >Looks like tar/zip attachments are getting removed.
>> >
>> >Uploaded same in google drive now.
>> >
>> >Please let me know if you can access the same or not.
>> >
>> >https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8
>> >
>> >Thanks,
>> >Durga Srinivasu
>> >
>> >
>> >On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
>> >durgasriniv...@gmail.com> wrote:
>> >
>> >> Mark,
>> >>
>> >> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle. Just
>> >changed
>> >> index.jsp and added lib [mostly DOJO] folder content to reproduce.
>> >>
>> >> If we deploy this in latest 8.5.9 with http2 enabled in chrome we are
>> >> seeing the SPDY compression errors
>> >>
>> >> Please let me know if this helps.
>> >>
>> >> Thanks,
>> >> Durga Srinivasu
>> >>
>> >>
>> >>
>> >> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas <ma...@apache.org>
>> >wrote:
>> >>
>> >>> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
>> >>> > Do i need to post in any other forum?
>> >>>
>> >>> No, you are in the right place.
>> >>>
>> >>> You mentioned the issue was reproducible with the Dojo libraries. If
>> >you
>> >>> can provide the simplest possible set of steps to recreate this
>> >issue
>> >>> from a clean Tomcat 8.5.9 install that would be a big help.
>> >>>
>> >>> Mark
>> >>>
>> >>> >
>> >>> > Thanks,
>> >>> > Durga Srinivasu
>> >>> >
>> >>> > On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
>> >>> > <durgasriniv...@gmail.com <mailto:durgasriniv...@gmail.com>>
>> >wrote:
>> >>> >
>> >>> > Hi,
>> >>> >
>> >>> > Any pointers please?
>> >>> >
>> >>> > Thanks,
>> >>> > Durga Srinivasu
>> >>> >
>> >>> > On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi
>> >>> > <durgasriniv...@gmail.com <mailto:durgasriniv...@gmail.com>>
>> >wrote:
>> >>> >
>> >>> > Hi,
>> >>> >
>> >>> > Recent chrome  [Mac - Sierra : Version  55.0.2883.87
>> >(64-bit) ]
>> >>> we are seeing issues in http2 sites.
>> >>> >
>> >>> >
>> >>> > Initially we have seen problem with http2 table header
>> >size
>> >>> limit error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9
>> >where
>> >>> tomcat has increased the header limit from 16K to 64K.
>> >>> >
>> >>> >
>> >>> > Now with latest tomcat 8.5.9 we are seeing
>> >>> ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
>> >>> >
>> >>> > Tried couple of steps (flush SPDY sokets etc) based on
>> >google
>> >>> search on this issue but nothing worked..
>> >>> >
>> >>> >
>> >>> > Inline image 1
>> >>> >
>> >>> > t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
>> >>> >
>> >>> > t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS
>> >[dt=36]
>> >>> >
>> >>> > t=10549 [st=37] 

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

[Durga Srinivasu Karuturi]

Its ~5MB file (ROOT app tar bundle).

I hope the information, which i have shared so far is useful enough to
reproduce the problem locally.

Please let me know if i missed any other information.

Thanks,
Durga Srinivasu


On Tue, Dec 20, 2016 at 7:42 AM, Sreeraj V P <sree...@entesos.com> wrote:

> yes.. started download.. hadnt waited to complete.
>
> Sent from BlueMail ​
>
> On 19 Dec 2016, 3:27 p.m., at 3:27 p.m., Durga Srinivasu Karuturi <
> durgasriniv...@gmail.com> wrote:
> >Mark,
> >
> >Looks like tar/zip attachments are getting removed.
> >
> >Uploaded same in google drive now.
> >
> >Please let me know if you can access the same or not.
> >
> >https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8
> >
> >Thanks,
> >Durga Srinivasu
> >
> >
> >On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
> >durgasriniv...@gmail.com> wrote:
> >
> >> Mark,
> >>
> >> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle. Just
> >changed
> >> index.jsp and added lib [mostly DOJO] folder content to reproduce.
> >>
> >> If we deploy this in latest 8.5.9 with http2 enabled in chrome we are
> >> seeing the SPDY compression errors
> >>
> >> Please let me know if this helps.
> >>
> >> Thanks,
> >> Durga Srinivasu
> >>
> >>
> >>
> >> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas <ma...@apache.org>
> >wrote:
> >>
> >>> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
> >>> > Do i need to post in any other forum?
> >>>
> >>> No, you are in the right place.
> >>>
> >>> You mentioned the issue was reproducible with the Dojo libraries. If
> >you
> >>> can provide the simplest possible set of steps to recreate this
> >issue
> >>> from a clean Tomcat 8.5.9 install that would be a big help.
> >>>
> >>> Mark
> >>>
> >>> >
> >>> > Thanks,
> >>> > Durga Srinivasu
> >>> >
> >>> > On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
> >>> > <durgasriniv...@gmail.com <mailto:durgasriniv...@gmail.com>>
> >wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > Any pointers please?
> >>> >
> >>> > Thanks,
> >>> > Durga Srinivasu
> >>> >
> >>> > On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi
> >>> > <durgasriniv...@gmail.com <mailto:durgasriniv...@gmail.com>>
> >wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > Recent chrome  [Mac - Sierra : Version  55.0.2883.87
> >(64-bit) ]
> >>> we are seeing issues in http2 sites.
> >>> >
> >>> >
> >>> > Initially we have seen problem with http2 table header
> >size
> >>> limit error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9
> >where
> >>> tomcat has increased the header limit from 16K to 64K.
> >>> >
> >>> >
> >>> > Now with latest tomcat 8.5.9 we are seeing
> >>> ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
> >>> >
> >>> > Tried couple of steps (flush SPDY sokets etc) based on
> >google
> >>> search on this issue but nothing worked..
> >>> >
> >>> >
> >>> > Inline image 1
> >>> >
> >>> > t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
> >>> >
> >>> > t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS
> >[dt=36]
> >>> >
> >>> > t=10549 [st=37]HTTP2_STREAM_ERROR
> >>> >
> >>> >--> description = "ABANDONED
> >>> > (stream_id=139):
> >>> > https://10.104.118.174/webacs/lib/dijit/form/_ToggleB
> >>> uttonMixin.js.map
> >>> >
> ><https://10.104.118.174/webacs/lib/dijit/form/_ToggleButton
> >>> Mixin.js.map>"
> >>> >
> >>> >--> status = -363
> >>> >
> >>> >--> stream_id = 139
> >>> >
> >>> > t=10549

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

[Durga Srinivasu Karuturi]

The below are the changes I did in ROOT web app:

1.  Added dojo libraries and login.js in ROOT/lib
2.  Added DOJO bootstrap and some dojo reference code in index.jsp as below:


var djConfig = {
isDebug: false,
debugAtAllCosts: false,
parseOnLoad: false,
supportedBrowser: {
'IE': [11],
'FF': ['44+'],
'ESR': [38],
'Chrome': ['48+']
},
async: true
};
   




require([
"login",
], function(){
require([
"dojo/_base/declare",
"dojo/parser",
"dojo/aspect",
"dojo/has",
"dojo/request/xhr",
"dojo/dom-form",
"dojo/dom-attr",
"dijit/registry",
"dojo/dom-construct",
"dojo/hash",
"dojo/data/ItemFileWriteStore",
"dojo/domReady!"
], function(declare, parser, aspect, has, xhr, domForm,
domAttr, registry, domConstruct, do_hash){
parser.parse();
    });
    });





On Mon, Dec 19, 2016 at 4:09 PM, Mark Thomas <ma...@apache.org> wrote:

> On 19/12/2016 09:56, Durga Srinivasu Karuturi wrote:
> > Mark,
> >
> > Looks like tar/zip attachments are getting removed.
> >
> > Uploaded same in google drive now.
> >
> > Please let me know if you can access the same or not.
> >
> > https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8#
>
> I can.
>
> Generally, it is better to provide the steps. e.g.:
>
> Add this line to index.jsp:
> ...
>
> Download these libraries and add them in WEB-INF/lib
> http://...
>
> Mark
>
> >
> > Thanks,
> > Durga Srinivasu
> >
> >
> > On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
> > durgasriniv...@gmail.com> wrote:
> >
> >> Mark,
> >>
> >> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle. Just
> changed
> >> index.jsp and added lib [mostly DOJO] folder content to reproduce.
> >>
> >> If we deploy this in latest 8.5.9 with http2 enabled in chrome we are
> >> seeing the SPDY compression errors
> >>
> >> Please let me know if this helps.
> >>
> >> Thanks,
> >> Durga Srinivasu
> >>
> >>
> >>
> >> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas <ma...@apache.org> wrote:
> >>
> >>> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
> >>>> Do i need to post in any other forum?
> >>>
> >>> No, you are in the right place.
> >>>
> >>> You mentioned the issue was reproducible with the Dojo libraries. If
> you
> >>> can provide the simplest possible set of steps to recreate this issue
> >>> from a clean Tomcat 8.5.9 install that would be a big help.
> >>>
> >>> Mark
> >>>
> >>>>
> >>>> Thanks,
> >>>> Durga Srinivasu
> >>>>
> >>>> On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
> >>>> <durgasriniv...@gmail.com <mailto:durgasriniv...@gmail.com>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> Any pointers please?
> >>>>
> >>>> Thanks,
> >>>> Durga Srinivasu
> >>>>
> >>>> On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi
> >>>> <durgasriniv...@gmail.com <mailto:durgasriniv...@gmail.com>>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> Recent chrome  [Mac - Sierra : Version  55.0.2883.87 (64-bit)
> ]
> >>> we are seeing issues in http2 sites.
> >>>>
> >>>>
> >>>> Initially we have seen problem with http2 table header size
> >>> limit error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9
> where
> >>> tomcat has increased the header limit from 16K to 64K.
> >>>>
> >>>>
> >>>> Now with latest tomcat 8.5.9 we are seeing
> >>> ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
> >>>>
> >>>> Tried couple of s

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

[Durga Srinivasu Karuturi]

Mark,

Looks like tar/zip attachments are getting removed.

Uploaded same in google drive now.

Please let me know if you can access the same or not.

https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8

Thanks,
Durga Srinivasu


On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
durgasriniv...@gmail.com> wrote:

> Mark,
>
> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle. Just changed
> index.jsp and added lib [mostly DOJO] folder content to reproduce.
>
> If we deploy this in latest 8.5.9 with http2 enabled in chrome we are
> seeing the SPDY compression errors
>
> Please let me know if this helps.
>
> Thanks,
> Durga Srinivasu
>
>
>
> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
>> > Do i need to post in any other forum?
>>
>> No, you are in the right place.
>>
>> You mentioned the issue was reproducible with the Dojo libraries. If you
>> can provide the simplest possible set of steps to recreate this issue
>> from a clean Tomcat 8.5.9 install that would be a big help.
>>
>> Mark
>>
>> >
>> > Thanks,
>> > Durga Srinivasu
>> >
>> > On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
>> > <durgasriniv...@gmail.com <mailto:durgasriniv...@gmail.com>> wrote:
>> >
>> > Hi,
>> >
>> > Any pointers please?
>> >
>> > Thanks,
>> > Durga Srinivasu
>> >
>> > On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi
>> > <durgasriniv...@gmail.com <mailto:durgasriniv...@gmail.com>> wrote:
>> >
>> > Hi,
>> >
>> > Recent chrome  [Mac - Sierra : Version  55.0.2883.87 (64-bit) ]
>> we are seeing issues in http2 sites.
>> >
>> >
>> > Initially we have seen problem with http2 table header size
>> limit error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9 where
>> tomcat has increased the header limit from 16K to 64K.
>> >
>> >
>> > Now with latest tomcat 8.5.9 we are seeing
>> ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
>> >
>> > Tried couple of steps (flush SPDY sokets etc) based on google
>> search on this issue but nothing worked..
>> >
>> >
>> > Inline image 1
>> >
>> > t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
>> >
>> > t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS  [dt=36]
>> >
>> > t=10549 [st=37]HTTP2_STREAM_ERROR
>> >
>> >--> description = "ABANDONED
>> > (stream_id=139):
>> > https://10.104.118.174/webacs/lib/dijit/form/_ToggleB
>> uttonMixin.js.map
>> > <https://10.104.118.174/webacs/lib/dijit/form/_ToggleButton
>> Mixin.js.map>"
>> >
>> >--> status = -363
>> >
>> >--> stream_id = 139
>> >
>> > t=10549 [st=37] -HTTP_TRANSACTION_READ_HEADERS
>> >
>> > * --> net_error = -363
>> > (ERR_SPDY_COMPRESSION_ERROR)*
>> >
>> > t=10549 [st=37]   -URL_REQUEST_START_JOB
>> >
>> > *   --> net_error = -363
>> > (ERR_SPDY_COMPRESSION_ERROR)*
>> >
>> > t=10549 [st=37]URL_REQUEST_DELEGATE  [dt=0]
>> >
>> > t=10549 [st=37] -REQUEST_ALIVE
>> >
>> >  --> net_error = -363
>> (ERR_SPDY_COMPRESSION_ERROR)
>> >
>> >
>> > Initial content is downloaded (other JS files etc) but on some
>> dojo libraries alone, we are this issue which make application home page
>> load fails.
>> >
>> >
>> > Firefox works!
>> >
>> >
>> > We are having latest tomcat 8.5.9 already. Not sure where else
>> problem now. We have not enabled any compression server side.
>> >
>> >
>> > https://bugs.chromium.org/p/chromium/issues/detail?id=673315
>> > <https://bugs.chromium.org/p/chromium/issues/detail?id=673315>
>> (Chrome bugs i have raised)
>> >
>> > My guess is that the bug is in Tomcat, in that it does not
>> send an HPACK dynamic table size update (so the dynamic table should be the
>> default 4 kB) but uses a 64 kB dynamic table.
>> > As soon as it references entries that are in fact already
>> emitted, that's a compression error.
>> > See https://www.ietf.org/mail-arch
>> ive/web/httpbisa/current/msg27867.html
>> > <https://www.ietf.org/mail-archive/web/httpbisa/current/msg
>> 27867.html> for a discussion on how to interpret the specs.
>> >
>> > According to the chrome bug notes problem is with tome dynamic
>> table size 64k. I don't know how to confirm this is as tomcat issue as well.
>> >
>> > Can somebody help here to trace the problem?
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

[Durga Srinivasu Karuturi]

Do i need to post in any other forum?

Thanks,
Durga Srinivasu

On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi <
durgasriniv...@gmail.com> wrote:

> Hi,
>
> Any pointers please?
>
> Thanks,
> Durga Srinivasu
>
> On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi <
> durgasriniv...@gmail.com> wrote:
>
>> Hi,
>>
>> Recent chrome  [Mac - Sierra : Version  55.0.2883.87 (64-bit) ] we are 
>> seeing issues in http2 sites.
>>
>>
>> Initially we have seen problem with http2 table header size limit error and 
>> to fix this, we have upgraded tomcat 8.5.4 to 8.5.9 where tomcat has 
>> increased the header limit from 16K to 64K.
>>
>>
>> Now with latest tomcat 8.5.9 we are seeing  ERR_SPDY_COMPRESSION_ERROR while 
>> loading dojo libraries.
>>
>> Tried couple of steps (flush SPDY sokets etc) based on google search on this 
>> issue but nothing worked..
>>
>>
>> [image: Inline image 1]
>>
>> t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
>>
>> t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS  [dt=36]
>>
>> t=10549 [st=37]HTTP2_STREAM_ERROR
>>
>>--> description = "ABANDONED (stream_id=139):
>> https://10.104.118.174/webacs/lib/dijit/form/_ToggleButtonMixin.js.map;
>>
>>--> status = -363
>>
>>--> stream_id = 139
>>
>> t=10549 [st=37] -HTTP_TRANSACTION_READ_HEADERS
>>
>> * --> net_error = -363 (ERR_SPDY_COMPRESSION_ERROR)*
>>
>> t=10549 [st=37]   -URL_REQUEST_START_JOB
>>
>> *   --> net_error = -363 (ERR_SPDY_COMPRESSION_ERROR)*
>>
>> t=10549 [st=37]URL_REQUEST_DELEGATE  [dt=0]
>>
>> t=10549 [st=37] -REQUEST_ALIVE
>>
>>  --> net_error = -363 (ERR_SPDY_COMPRESSION_ERROR)
>>
>>
>> Initial content is downloaded (other JS files etc) but on some dojo 
>> libraries alone, we are this issue which make application home page load 
>> fails.
>>
>>
>> Firefox works!
>>
>>
>> We are having latest tomcat 8.5.9 already. Not sure where else problem now. 
>> We have not enabled any compression server side.
>>
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=673315 (Chrome bugs i 
>> have raised)
>>
>> My guess is that the bug is in Tomcat, in that it does not send an HPACK 
>> dynamic table size update (so the dynamic table should be the default 4 kB) 
>> but uses a 64 kB dynamic table.
>> As soon as it references entries that are in fact already emitted, 
>> that's a compression error.
>> See https://www.ietf.org/mail-archive/web/httpbisa/current/msg27867.html 
>> for a discussion on how to interpret the specs.
>>
>> According to the chrome bug notes problem is with tome dynamic table size 
>> 64k. I don't know how to confirm this is as tomcat issue as well.
>>
>> Can somebody help here to trace the problem?
>>
>>
>>
>>
>>
>>
>

Re: ERR_SPDY_COMPRESSION_ERROR

[Durga Srinivasu Karuturi]

Hi,

Any pointers please?

Thanks,
Durga Srinivasu

On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi <
durgasriniv...@gmail.com> wrote:

> Hi,
>
> Recent chrome  [Mac - Sierra : Version  55.0.2883.87 (64-bit) ] we are seeing 
> issues in http2 sites.
>
>
> Initially we have seen problem with http2 table header size limit error and 
> to fix this, we have upgraded tomcat 8.5.4 to 8.5.9 where tomcat has 
> increased the header limit from 16K to 64K.
>
>
> Now with latest tomcat 8.5.9 we are seeing  ERR_SPDY_COMPRESSION_ERROR while 
> loading dojo libraries.
>
> Tried couple of steps (flush SPDY sokets etc) based on google search on this 
> issue but nothing worked..
>
>
> [image: Inline image 1]
>
> t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
>
> t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS  [dt=36]
>
> t=10549 [st=37]HTTP2_STREAM_ERROR
>
>--> description = "ABANDONED (stream_id=139):
> https://10.104.118.174/webacs/lib/dijit/form/_ToggleButtonMixin.js.map;
>
>--> status = -363
>
>--> stream_id = 139
>
> t=10549 [st=37] -HTTP_TRANSACTION_READ_HEADERS
>
> * --> net_error = -363 (ERR_SPDY_COMPRESSION_ERROR)*
>
> t=10549 [st=37]   -URL_REQUEST_START_JOB
>
> *   --> net_error = -363 (ERR_SPDY_COMPRESSION_ERROR)*
>
> t=10549 [st=37]URL_REQUEST_DELEGATE  [dt=0]
>
> t=10549 [st=37] -REQUEST_ALIVE
>
>  --> net_error = -363 (ERR_SPDY_COMPRESSION_ERROR)
>
>
> Initial content is downloaded (other JS files etc) but on some dojo libraries 
> alone, we are this issue which make application home page load fails.
>
>
> Firefox works!
>
>
> We are having latest tomcat 8.5.9 already. Not sure where else problem now. 
> We have not enabled any compression server side.
>
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=673315 (Chrome bugs i 
> have raised)
>
> My guess is that the bug is in Tomcat, in that it does not send an HPACK 
> dynamic table size update (so the dynamic table should be the default 4 kB) 
> but uses a 64 kB dynamic table.
> As soon as it references entries that are in fact already emitted, that's 
> a compression error.
> See https://www.ietf.org/mail-archive/web/httpbisa/current/msg27867.html 
> for a discussion on how to interpret the specs.
>
> According to the chrome bug notes problem is with tome dynamic table size 
> 64k. I don't know how to confirm this is as tomcat issue as well.
>
> Can somebody help here to trace the problem?
>
>
>
>
>
>

Chrome 55 - ERR_SPDY_COMPRESSION_ERROR

[Durga Srinivasu Karuturi]

Hi,

Recent chrome  [Mac - Sierra : Version  55.0.2883.87 (64-bit) ] we are
seeing issues in http2 sites.


Initially we have seen problem with http2 table header size limit
error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9 where
tomcat has increased the header limit from 16K to 64K.


Now with latest tomcat 8.5.9 we are seeing  ERR_SPDY_COMPRESSION_ERROR
while loading dojo libraries.

Tried couple of steps (flush SPDY sokets etc) based on google search
on this issue but nothing worked..


[image: Inline image 1]

t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST

t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS  [dt=36]

t=10549 [st=37]HTTP2_STREAM_ERROR

   --> description = "ABANDONED (stream_id=139):
https://10.104.118.174/webacs/lib/dijit/form/_ToggleButtonMixin.js.map;

   --> status = -363

   --> stream_id = 139

t=10549 [st=37] -HTTP_TRANSACTION_READ_HEADERS

* --> net_error = -363 (ERR_SPDY_COMPRESSION_ERROR)*

t=10549 [st=37]   -URL_REQUEST_START_JOB

*   --> net_error = -363 (ERR_SPDY_COMPRESSION_ERROR)*

t=10549 [st=37]URL_REQUEST_DELEGATE  [dt=0]

t=10549 [st=37] -REQUEST_ALIVE

 --> net_error = -363 (ERR_SPDY_COMPRESSION_ERROR)


Initial content is downloaded (other JS files etc) but on some dojo
libraries alone, we are this issue which make application home page
load fails.


Firefox works!


We are having latest tomcat 8.5.9 already. Not sure where else problem
now. We have not enabled any compression server side.


https://bugs.chromium.org/p/chromium/issues/detail?id=673315 (Chrome
bugs i have raised)

My guess is that the bug is in Tomcat, in that it does not send an
HPACK dynamic table size update (so the dynamic table should be the
default 4 kB) but uses a 64 kB dynamic table.
As soon as it references entries that are in fact already emitted,
that's a compression error.
See https://www.ietf.org/mail-archive/web/httpbisa/current/msg27867.html
for a discussion on how to interpret the specs.

According to the chrome bug notes problem is with tome dynamic table
size 64k. I don't know how to confirm this is as tomcat issue as well.

Can somebody help here to trace the problem?