empty 500 error pages in fedora 3.8

[Rebecca Sutton Koeser]

Hey, fedora folks.

Working on upgrading to Fedora 3.8 (as a stepping stone to 4), and ran into a problem where our 500 error pages are completely empty - no stack trace to indicate what kind of error occurred.  As far as we can tell this is something to do with fedora and not tomcat (e.g., I still see stack traces on the risearch for bad queries).  We¹ve looked up information about tomcat 500 error configuration, but the things we¹ve found don¹t seem immediately relevant and nothing we¹ve tried has made any difference. I don¹t see any differences in the error configuration or the error jsp files between 3.8 and our older version of fedora (3.4), and I have looked and can¹t find any jira tickets that seem relevant.  I can see why showing the stack trace could be a security issue, but still think (hope) there should be a way to display it if you need to.

Our software relies on the stack traces to differentiate what kind of error occurred (some errors are more ok than others).  If we have to work around it we can, but it will take some work, so it would be by far preferable if there is a configuration we can turn on to get those 500 error messages back.

Hoping someone else has run into this and knows the answer.  I would at least appreciate hearing if other folks are getting empty or non-empty 500 errors in fedora 3.8.

Thanks.

[Benjamin Armintor]

I don't remember any work done with the intention of suppressing the entity on a 500 response, but I'm also fairly certain that the test suite only verifies status codes (and a lot has changed over the last 4 minor releases). I think, for example, that in 3.5 a whole category of 500 errors was changed to return 400. How could we reproduce the 500s you're interested in?

- Ben

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

[Rebecca Sutton Koeser]

On Tuesday, July 14, 2015 at 5:17:11 PM UTC-4, Ben wrote:

I don't remember any work done with the intention of suppressing the entity on a 500 response, but I'm also fairly certain that the test suite only verifies status codes (and a lot has changed over the last 4 minor releases). I think, for example, that in 3.5 a whole category of 500 errors was changed to return 400. How could we reproduce the 500s you're interested in?

Ben, thanks for responding.

I saw the note in the documentation about 400 codes, but I haven't actually run into them yet; however, I am still getting 500s for known error cases in my eulfedora unit tests.  I think the most important case is to be able to catch/differentiate a checksum mismatch when adding or updating a datastream.  Here's a curl command you can use to test this (set credentials, server name, and pid for an existing object):

curl -v -u user:pass --http1.0 -d '<t>some text</t>' 'https://fedoraserver:8443/fedora/objects/changeme:1/datastreams/TEXT2?dsLabel=text+datastream&mimeType=text%2Fplain&checksumType=MD5&logMessage=creating+TEXT2&checksum=totally-bogus-not-even-an-MD5'

-v gives full details (in my case, this includes a status code 500, content length 0), omit the -v to see the response content (if there is one).  I checked my fedora logs and it does report a checksum mismatch for this call.

We've also got some cases where we load fixtures (generally for testing purposes) and check for "ObjectExistsException" in the response.  That one is probably easier to work around and less pervasive in our code.

[Benjamin Armintor]

My inclination is to think that this is related to the migration from Jersey to CXF: it doesn't look like the exception handling in the BaseRestResource class has changed in a way that would impact this in years. If you were looking for "org.fcrepo.server.errors.ValidationException: Checksum Mismatch:", that would always have been wrapped in thrown WebApplicationException, so dependent on the framework (I think).

There is some suggestion that this behavior is customizable via bean: https://cxf.apache.org/javadoc/latest/org/apache/cxf/jaxrs/impl/WebApplicationExceptionMapper.html

The source:

http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-rt-frontend-jaxrs/2.7.5/org/apache/cxf/jaxrs/impl/WebApplicationExceptionMapper.java#WebApplicationExceptionMapper.0addMessageToResponse

Points to setting the addMessageToResponse property, which I was able to coax into some kind of information by editing into the server/config/spring/web/jaxrs/objects-jaxrs.xml config file:

<jaxrs:providers>

      <bean class="org.fcrepo.server.rest.cxf.WadlGenerator" />

<!-- new content below -->

      <bean class="org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper">

        <property name="addMessageToResponse" value="true" />

      </bean>

    </jaxrs:providers>

 

With that config (admittedly against a 3.7.1 server, but I'm confident!) I got an entity of:

WebApplicationException has been caught, status: 500, message: Checksum Mismatch

... If that's too little information, I think you could write a implementation and wire it in there with little trouble. But I'm hopeful that simple entity would be sufficient?

- Ben

--

[Rebecca Sutton Koeser]

Ben, thank you so much! This works.  The error responses are slightly different than the stack trace messages we were getting before, but it's definitely enough to differentiate the kinds of errors we're looking for, so it's sufficient for our purposes.  I doubt we would have been able to figure this out on our own, so I very much appreciate you looking into this and figuring out a solution.