www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - arsd.cgi - maximum length of form post

reply bachmeier <no spam.net> writes:
I'm using arsd.cgi, and have a form set up to take input. I get a 
range violation error core.exception.RangeError test.d(109): 
Range violation when using the embedded server. It appears to be 
because the input is too large (about 3900 characters). When I 
cut the input to 3000 characters, there is no error.

Is there a way to increase the maximum post size?
Dec 12 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 13 December 2016 at 00:48:44 UTC, bachmeier wrote:
 Is there a way to increase the maximum post size?
The second argument to GenericMain is the max content length, it has a default of 5,000,000. http://dpldocs.info/experimental-docs/arsd.cgi.GenericMain.html http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L182 But that shouldn't be changing anything around 3000....
Dec 12 2016
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 13 December 2016 at 00:48:44 UTC, bachmeier wrote:
 a range violation error core.exception.RangeError test.d(109): 
 Range violation
What's that line of your code too?
Dec 12 2016
parent reply bachmeier <no spam.net> writes:
On Tuesday, 13 December 2016 at 00:54:43 UTC, Adam D. Ruppe wrote:
 On Tuesday, 13 December 2016 at 00:48:44 UTC, bachmeier wrote:
 a range violation error core.exception.RangeError test.d(109): 
 Range violation
What's that line of your code too?
Here is a minimal program that can replicate the problem. Compiled and run with dmd finderror.d cgi.d -version=embedded_httpd ./finderror import arsd.cgi; import std.array, std.conv, std.datetime, std.file, std.process; string input() { return `<form action="submission" method="post"> <textarea name="note" rows="28" cols="95"></textarea><br> <input type="submit" value="Send"> </form>`; } string simpleHtmlEncode(string s) { return s.replace("&", "&amp;"). replace("<", "&lt;").replace(">", "&gt;"); } void handler(Cgi cgi) { cgi.setResponseContentType("text/html; charset=UTF-8"); string data; switch (cgi.pathInfo.simpleHtmlEncode()) { case "/": data = input(); break; case "/submission": string foo = cgi.post["note"]; break; default: data = "Not a valid page. Try again."; break; } cgi.write(data, true); } mixin GenericMain!handler;
Dec 13 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Well, I can reproduce the error now, the buffer it is getting is 
too long for some reason. Probably a slicing error that doesn't 
show up with smaller payloads.

I should have a fix today though.


BTW, interestingly, the more complex codepath for uploads does 
work fine (add enctype="multipart/form-data" to your HTML form to 
trigger it, you don't actually have to do an upload, that attr is 
enough) so you can do that as a work around in the mean time.

I prolly just actually tested large uploads and never did large 
normal submissions with the embedded server.
Dec 15 2016
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 13 December 2016 at 22:55:55 UTC, bachmeier wrote:
 Here is a minimal program that can replicate the problem. 
 Compiled and run with
OK, try the new git cgi.d version, looks like my popFront was buggy and some data got misplaced over multiple chunks (so if the content was less than one chunk length, it worked, but more than that it broke)
Dec 15 2016
parent bachmeier <no spam.net> writes:
On Thursday, 15 December 2016 at 16:52:54 UTC, Adam D. Ruppe 
wrote:
 On Tuesday, 13 December 2016 at 22:55:55 UTC, bachmeier wrote:
 Here is a minimal program that can replicate the problem. 
 Compiled and run with
OK, try the new git cgi.d version, looks like my popFront was buggy and some data got misplaced over multiple chunks (so if the content was less than one chunk length, it worked, but more than that it broke)
That fixed it. Thanks! I use it to capture notes inside a Git repo as I work. My posts are normally short, but in this case I did copy and paste with a lengthy email, and that was apparently enough to trigger the bug.
Dec 15 2016