We have seen a similar issue to this in the past, but not with this exact output - namely the 403 error.
Previously, during EAD imports we sometimes had issues with this - the Library of Congress servers would be down or unavailable, and then EAD import would fail. Eventually, we addressed this by storing a local copy of the EAD 2002 DTD in AtoM itself, so it no longer needs LoC to be available to complete an import.
However, when we export EAD, we want it to be valid and usable outside of AtoM, so following the expected conventions, we add the LoC DTD URI to the DOCTYPE and EAD header information, rather than a path to a locally stored file in AtoM.
When AtoM generates a finding aid, it first generates the EAD, and then it uses XSLT stylesheets to transform that XML into a PDF (or an RTF document, depending on your settings). So, the EAD XML is the basis used for generating the finding aid.
We have seen cases where the same timeout issues occur trying to reach the LoC DTD during finding aid generation, and have an issue filed for this:
However, I see that the error returned in your case is not exactly the same - rather than the process timing out while trying to reach the Library of Congress DTD, it actually returned a 403 error. A 403 HTTP status code typically means "forbidden" - i.e. access denied.
Now, the EAD DTD *should* be public so this is a strange outcome. There are two possible reasons I can think of immediately:
- The Library of Congress server hosting the EAD 2002 DTD is down or has been moved etc and the old address is now forbidden
- Your site is on a VPN or behind a firewall that does not allow public access
Additionally: A) I have checked, and finding aid generation is working for me in 2.6. If the redirect were the issue, then no one using AtoM should be able to generate finding aids without encountering this issue. B) a 403 is not a typical response when a redirect is encountered, even if there is some reason why the CLI task can't follow it. It's also not the response you would expect if the problem was from the LoC server being temporarily down - such an error wouldn't return a 403 Forbidden status code, but would look more like the timeout output shown on issue #13247
. This suggests to me that there is something else going on.
So far, based on this, my guess would be that issue 2 might be what's the case. Does your AtoM instance have access to the public web?
Regardless of your answer or whether or not hypothesis 2 is even correct, I have another idea that might help work around the issue.
Returning to issue #13247
for a moment: we haven't yet found an ideal solution to this issue, since we still want to conform to the EAD and XML conventions and properly reference the publicly available DTD in the EAD's header information.
In the meantime, there is a proposed workaround on the ticket (see note-4
) that may work in your case, as it removes the need to contact LoC:
Workaround (removing the 2nd line in plugins/sfEadPlugin/modules/sfEadPlugin/templates/indexSuccessHeader.xml.php ) helped with the issue.
Here is the file:
As you can see, it's just 2 lines. You can comment out the second one locally and see if that solves the issue. In PHP, you can comment out lines by adding two slashes before it, like so:
<?php echo '<?xml version="1.0" encoding="'.sfConfig::get('sf_charset', 'UTF-8')."\" ?>\n" ?>
// <!DOCTYPE ead PUBLIC "+//ISBN 1-931666-00-8//DTD ead.dtd (Encoded Archival Description (EAD) Version 2002)//EN" "http://lcweb2.loc.gov/xmlcommon/dtds/ead2002/ead.dtd">
Let us know if this helps,