Bug 2283 - Poor use of "Not Found" redirect in response to corrupt MARC record
Summary: Poor use of "Not Found" redirect in response to corrupt MARC record
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P3 normal (vote)
Assignee: Galen Charlton
QA Contact:
URL: http://kohaserver:8080/cgi-bin/koha/c...
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-27 08:29 UTC by Chris Cormack
Modified: 2013-12-05 20:04 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
gif of typical 404 notice, with filepath (Joe Tholen / Kansas) (8.14 KB, image/gif)
2009-05-21 18:34 UTC, Chris Cormack
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:48:55 UTC


---- Reported by mjr@ttllp.co.uk 2008-06-27 08:29:20 ----

Trying to access detail.pl for a biblio with a corrupt MARC record results in a redirection to 404.pl (without a status code, too).  This confuses librarians and makes it harder for them to report bugs (because the location bar changes).

I checked it's a MARC problem that causes these with the command line:-

perl -MC4::Biblio -e 'print GetMarcBiblio(118);'
 problem with :118 : Premature end of data in tag subfield line 47
Premature end of data in tag datafield line 46
Premature end of data in tag record line 2 at /Library/Perl/5.8.6/darwin-thread-multi-2level/XML/LibXML/SAX.pm line 64
 at /Library/Perl/5.8.6/MARC/File/XML.pm line 448

The offending lines of detail.pl are:-

my $record           = GetMarcBiblio($biblionumber);

unless (defined($record)) {
    print $query->redirect("/cgi-bin/koha/errors/404.pl");
        exit;
}


I'm not sure of the best way to fix this: can we recover gracefully from parse errors in the MARC or at least report those errors back to the user?



---- Additional Comments From joetho@gmail.com 2009-05-21 18:34:24 ----

Created an attachment
gif of typical 404 notice, with filepath (Joe Tholen / Kansas)





--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:48 UTC  ---

This bug was previously known as _bug_ 2283 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2283
Imported an attachment (id=598)

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was mjr@ttllp.co.uk.
The original submitter of attachment 598 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Owen Leonard 2013-01-15 15:52:35 UTC
I'm assuming this bug is still valid but I wonder how it can be tested? Can one manually corrupt a MARC record to duplicate the problem?
Comment 2 MJ Ray (software.coop) 2013-01-16 10:40:53 UTC
I would expect manual corruption to work but I've not tested it recently. If you would like to: truncate contents of biblioitems.marcxml in mysql and then try to view the detail page again.
Comment 3 Tomás Cohen Arazi 2013-02-28 15:03:15 UTC
This was addressed in bug 5791, I think this should be marked as RESOLVED - FIXED.
Comment 4 MJ Ray (software.coop) 2013-03-01 13:28:55 UTC
Yes, that fix removed the redirect. I agree.