[OPEN-ILS-DEV] bug in 1.6 client if very long 856?

[Dan Scott]

To follow up on this:

On Fri, May 6, 2011 at 10:19 AM, Dan Scott <dan at coffeecode.net> wrote:
> On Fri, May 06, 2011 at 11:00:19AM -0300, Melissa Belvadi wrote:
>>
>> Hello, all.
>> We've run into an error in the staff client  (both Mac and PC versions)
>> in 1.6.0.4.
>>
>> We checked with Equinox and they agree that the problem is likely to be
>> some kind of internal limit on how long an 856 $u URL can be, since we
>> only see the problem when editing records with long ones.  We're not
>> sure what the limit actually is, but the sample below apparently
>> surpasses it. Maybe we're wrong about the issue being length - maybe it
>> is something to do with the punctuation used in the URL, but if so, I
>> can't isolate the problem, and either way we need it fixed because these
>> are legitimate URLs that we need in our records.
>
> I can't think of any reason why there would be a limit on the length of
> the URLs; that makes no sense to me. See below for a pertinent question
> though.

Perhaps the number of 856 fields in a given record? I fixed a number
of problems in this area in the 1.6.1.x release series, and then fixed
the same sort of problems in 2.0.x. I can't remember exactly how
1.6.0.x worked - we upgraded to 1.6.1.x a year ago - but seem to
recall that it was very unhappy with more than one 856 located URI in
a single record.

Although - come to think of it - Evergreen generally doesn't treat an
856 field differently from any other fields unless it contains a
subfield 9 or w or n (signifying a located URI). So, this is very
strange as none of those subfields appear to be in play.

> As to the 856 issue - does your $u subfield really contain two copies of
> the URL, like "http://url (http://url)", as the snippet below shows?
> This would be unexpected, contrary to spec, and certainly could trip up
> naive code that is expecting to just have a URL in the $u subfield. Our
> code should be more defensive and not throw a horrible error, but I
> strongly suspect the problem is with the second copy of the URL in
> brackets in your $u.

To answer my own question,
http://islandpines.roblib.upei.ca/opac/extras/supercat/retrieve/marcxml/record/847956
shows that there is just one URL in each 856 field - so GroupWise must
have "helpfully" added the second copy.

Given that there are no 9/w/n subfields in the 856 fields, that leaves
us with the possibility that the parentheses and ampersands and
escaped characters in the URL are giving something in the ingest code
fits. When I get a chance, I'll see if I can reproduce that problem in
2.0.6 using the same URLs as your record contains. (But it would be
great if someone on 2.0.6 beat me to the punch!)

-- 
Dan Scott
Laurentian University