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

[Dan Wells]

Hello all,

I spent a few more minutes boiling this down today, and it looks like the problem is in the OSRF gateway itself.  This can be seen very simply by sending a fake test url to any OSRF gateway which includes the trouble sequence.  For instance: (and note: %25 in the following examples is the URL encode for '%', and I am leaving the quotes unencoded for clarity, as it seems to not matter)

http://75.101.133.94/osrf-gateway-v1?service=test&method=test&param="%251a"

successfully returns an empty payload:

{"payload":[],"status":200}

but if we change the 'a' to an 'n':

http://75.101.133.94/osrf-gateway-v1?service=test&method=test&param="%251n"

the gateway fails to return any data at all.  I tested this on a handful of Evergreen catalogs with identical results, but did find one with a slightly more useful result:

http://demo.evergreencatalog.com/osrf-gateway-v1?service=test&method=test&param="%251n"

This machine, for whatever reason, displays a stock HTTP 500:

An internal server error occurred. Please try again later.



Peeking in my Apache error logs, I finally found a useful trail to follow:

"*** %n in writable segment detected ***"

At that point I had to shelve this for now, especially not being very familiar with the OSRF code, but I am guessing someone else can find the apparently rogue printf much faster than I can in any case.


Dan



>>> On 5/6/2011 at 4:02 PM, Brian Feifarek <bfeifarek at q.com> wrote:

> The community server at http://75.101.133.94 has 2.0.6 available if anybody 
> has the time to try the process there.
> Brian
> 
>> Date: Fri, 6 May 2011 12:26:50 -0400
>> From: dan at coffeecode.net 
>> To: open-ils-dev at list.georgialibraries.org 
>> Subject: Re: [OPEN-ILS-DEV] bug in 1.6 client if very long 856?
>> 
>> To follow up on this:
>> > 
>> 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
>