Here is another use-case where someone needs SRU/POST.
------- Start of forwarded message -------
Envelope-to: [log in to unmask]
Delivery-date: Thu, 07 Jul 2005 15:39:25 +0200
Date: Thu, 07 Jul 2005 15:38:59 +0200
From: Ko van der Sloot <[log in to unmask]>
X-Accept-Language: en-us, en
To: yaz <[log in to unmask]>
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uvt.nl
Subject: [Yazlist] large HTTP GET's
Reply-To: "Discussion on the YAZ Z39.50 toolkit" <[log in to unmask]>
Sender: [log in to unmask]
X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on bagel.indexdata.dk
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
We encountered the following problem(s):
We have an SRU/SRW service build, based on the Generic File Server.
One of our applications tries to send very large (>16.000 bytes) GET
requests to the service.
This fails with an HTTP 500 message.
The reason is that in comstack.c there is a 8192 byte limit set to HTTP
headers. (in cs_complete_auto)
I can see some reason behind limitting. But why not some more?
According to RFC 2616 3.2.1 URI's can be of unbound length. Which is
maybe a bit to much ;)
But anyawy: If the limit is exceeded, an 414 (Request-URI Too Long)
should be returned.
Lifting the limit solves our problem.
Then we also tried converting GET to POST.
This fails because the yaz_sru_decode() function (in srwutil.c) only
It was not that difficult to add some code to handle POST, but i'm not
so sure that it is an optimal/general/conforming solution.
So what to do now?
We could propose a patch to raise the HTTP header limit to "unbounded"
We could propose a patch to add POST support to SRU. (We have a working
We could do both.
Ko vd Sloot
Yazlist mailing list
[log in to unmask]
------- End of forwarded message -------