Open joewiz opened 4 years ago
@windauer also commented in chat based on his observations of the logs:
The later part provides us a pointer in the database: /exist/apps/hsg-shell/historicaldocuments/frus-history/b_806
When opening hsg-prod-backend1.hsg:8080/exist/apps/hsg-shell/historicaldocuments/frus-history/b_806 the URL is rewritten to http://hsg-prod-backend1.hsg:8080/exist/apps/hsg-shell/historicaldocuments/frus-history/chapter-5#b_806, the page open perfectly fine in the browser and I see all the mentioned errors in the logs. My current suspicion is that there is a mechanism in place that trieds to resolve /frus-history/b_806 in different ways and if one fails it tries another. As said from an end user point of view everything works fine but the error messages are anoying in the logfile and if you are fine with it Joe I’d like to create a ticket for this one to get rid of the errors after the holidays
The ebook edition was produced using the old code. Here's a screenshot:
In the frus-history index (see the source TEI), range-based cross references are encoded in a unique way, which hsg-shell's ODD isn't parsing the same way as our pre-TEI Publisher site, and seems to be causing server errors.
Here is a sample encoded cross reference:
The syntax used in the first of these two
@target
attributes is based on the TEI Guidelines' support for XPointer; I only use therange
pointer scheme. Specifically, the cross reference points to the range between two<anchor>
elements with@xml:id
elements in the body of the book:My original handling for this, on our pre-TEI Publisher-based website, was to examine where the targets were located, and replace the book's original "196–199, 203, 206" with a web-relevant description of the target section, e.g., "Ch. 8 paras 34–39, Ch. 8 para 47, Ch. 8 para 52".
The Internet Archive contains a snapshot of the old rendering of the page.
"Ch. 8 paras 34–39, Ch. 8 para 47, Ch. 8 para 52" were given the URLs:
However, the current hsg site fails to parse the links correctly, generating URLs like this:
Our website performs a 302 redirect when these URLs, respectively, to:
... which appears to be a graceful recovery, but @windauer reported finding errors in the logs:
Here is the original code I wrote to transform the links:
We should research the logs to find the source of the error messages above, and, if needed, adapt the original link parsing code to our current ODD-based method for transforming TEI into HTML.