On May 31, 2005, at 8:25 AM, [EMAIL PROTECTED] wrote:
I have a particularly large form built with PerForm. The page is
located
in an area of the site which is protected by
Apache::AxKit::Plugin::Session. When I try to submit the form I get
the
following error message.
[libapreq] entity too large (2838, max=1024)
Apache::RequestNotes encountered a parsing error!
Even if I subclass my XSP page, to get some of the validation code
out of
there, it will still be larger than 1024 (not that I could get
pinheritance to work anyway!)
Yes, I have run into this particular problem myself. This is
actually a hard-coded limit in LibXSLT.c, in several places. If I
remember correctly, it is the number of array elements for the hash
(therefore the number of array elements need to be double the number
of parameters you would like to store).
Since this is happening within the actual stylesheet provider, this
will occur no matter what you do in your XSP. The solution, as far
as I have encountered this problem, is just to manually change these
values in source and recompile XML::LibXSLT on my system. I know it's
far from satisfactory, but it's worked for me.
If I disable A:A:P:S it works fine, so the problem must be down to
the way
A:A:P:S is handles the redirects. As far as I can tell, a redirect
gets
issued for every single page request.
The problem in this instance is that AxKit populates the XSLT
parameter list automatically for URI query arguments, and any
parameters that need to be added by plugins or other modules. For
instance, Apache::AxKit::Plugin::AddXSLTParams::Request and
A:A:P:A:BasicSession both populate the parameter list with their own
bits of data. Once you start adding a large number of keys to your
cookies in addition to form fields, this can fill up quite quickly.
--
Michael Nachbaur <[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
