> Thanks for confirming that the last revision is not working as expected.
> Now we are back at the beginning. Could you apply this patch [1] and
> report back if it resolves your issue please?
Yes! That fixed it for us.
Sorry again for the run around.
Allen
> Let's recapitulate: You are currently running +deb7u4 from April 2016
> which is the last good version for you and you see 400 errors when you
> use +deb7u5 or any later version up to +deb7u10, correct? Then this is a
> different issue because Samuel reported that the 400 errors occurred
> when h
First off, thanks for your patience. The thing I was missing was that the
build procedure for Debian includes applying patches to the code. I was
following the build instructions from the BUILDING.txt file, which doesn't
include the Debian-specific instructions. That completely explains what
> That is strange. You have mentioned in your previous email that you
> downgraded tomcat7 in Wheezy to version 7.0.28-4+deb7u4. Are you sure
> that you are not comparing this version with 7.0.28-4+deb7u10? Why
> didn't you downgrade to 7.0.28-4+deb7u9 in the first place? This would
> explain the d
The plot thickens! I created a local build from git using the
7.0.28-4+deb7u10 tag. Interestingly when I did that I was unable to
reproduce the problem. Originally I suspected that there was something
wrong with my build. But after some digging, I'm starting to suspect the
official build.
We are seeing the same thing that Samuel Wolf described, but from our web
UI and with 7.0.28-4+deb7u10. We get seemingly random 400 HTTP returns.
We downgraded to 7.0.28-4+deb7u4 and that problem went away.
Unfortunately in our environment the Tomcat-side Java exception is not
being logged, so
6 matches
Mail list logo