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

[Mike Rylander]

On Mon, May 9, 2011 at 6:18 PM, Dan Wells <dbw2 at calvin.edu> wrote:
> 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 ***"

That, google suggests, means that we might want to try adding
-D_FORTIFY_SOURCE=1 to our CFLAGS.  See: http://bugs.gentoo.org/290619

Anyone game for trying that theory out?

Alternatively, we may be looking at a use of the old-style
printf-based buffer builder.  We don't need that, I think, in the case
of params -- we can just dup the string.

--miker

>
> 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
>>
>
>



-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com