Dear Gustaf (and all) thanks Gustaf for the fixes - reading your code, it's interesting to see how AOLserver works internally. And it's all so elegant, meaning even I can follow it! I can confirm your fix has resolved the 413 problem. I attempted to take it a step further and add a 413 redirect to the config.tcl as follows:
ns_section ns/server/${server}/redirects
ns_param 413 "/global/file-too-large.html"
However, this caused AOLserver to crash when uploading large files. After some
debugging, I figured out a solution to unmark the connection once the redirect
has been called (patch to op.c attached). Obviously, please let me know if
there is a better way.
I also added a new TCL proc 'ns_returntoolarge' which maps to the
Ns_ConnReturnEntityTooLarge C function. I find these TCL procs handy as an
alternative to the config.tcl redirects, as they can be overloaded if needed.
Patches to tclcmds.c and tclresp.c attached.
I'd love to hear any feedback that people have on these patches. As it's my
first time, I'd be very grateful if you could review them.
Best wishes
Brian
________________________________________
From: Gustaf Neumann [neum...@wu-wien.ac.at]
Sent: 09 July 2011 11:25
To: AOLserver Discussion
Cc: Fenton, Brian
Subject: Re: [AOLSERVER] Problem with file uploads larger than maxinput
Dear all,
A few minutes ago, i have committed a change to the
sourceforge aolserver repository that should should fix the
problem finally. The primary problem was not that the driver
replied directly to the client, but the fact that client
(e.g. firefox) has not yet sent the full request while the
server had already replied and closed the connection. Since
the handling of the header happens in aolserver before the
full request from the client is received, the server could
close the connection before the client has sent the full
request. So, although the client (e.g. firefox) has already
received a proper reply from aolserver, it complained about
the fact, that it could not sent the full request.
This explains, why the error handling worked reliably with
"small" upload files but not with large ones in current
browsers; it explains as well, that simple clients (like
"nc") worked always reliable.
Additionally, i have moved the reply handling to the
connection threads, and made some more cosmetical changes.
Brian, please check again.
-gustaf neumann
On 08.07.11 13:49, Fenton, Brian wrote:
> Dear Gustaf
>
> many thanks for the reply. Yes, I can confirm your results - if I set a limit
> of 10k and upload a file of 15k, it works perfectly for me.
>
> Would be great if you could look into this. If not, maybe you could give me a
> few pointers where to change the "request handling thread".
>
> many thanks
> Brian
>
> ________________________________________
> From: AOLserver Discussion [AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Gustaf
> Neumann [neum...@wu-wien.ac.at]
> Sent: 08 July 2011 12:20
> To: AOLSERVER@LISTSERV.AOL.COM
> Subject: Re: [AOLSERVER] Problem with file uploads larger than maxinput
>
> Dear Brian,
>
> Thanks with the config files, they are fine. With some more
> testing, i found some more insights: The version in CVS head
> returns always the right result to a client (tested with "nc
> -v localhost 8006< POST.txt"), no matter of the size of the
> uploaded content, but works only reliably in browsers
> (firefox, chrome) for rather small requests (set your
> maxupload to 5k, upload a 10 k file), and does reliable NOT
> work with upload files> 20MB (which is the interesting
> case). So, the problem looks like a timing/buffering problem
> to me. RFC 2616 says e.g.
>
> If the server chooses to close the connection immediately after sending
> the
> response, it SHOULD send a Connection header including the
> connection-token close.
>
>
> The reply of aolserver contains the "connection: close", so
> this seems standard compliant. The driver has to close the
> connection immediately after sending the reply, so, the
> moral of the story seems to be that we have to get the
> response handling out of the driver and require a solution
> via the request handling thread - what's the best solution
> anyhow. So far, i don't understand, why the size of the
> upload request changes the behavior.
>
> maybe, i can look into this next week.
>
> -gustaf neumann
>
>
> On 06.07.11 13:08, Fenton, Brian wrote:
>> Dear Gustaf
>>
>> thanks for the reply. I have tried it with the latest OpenACS config.tcl and
>> also another older one I use (both attached). I just assumed I was doing
>> something wrong, didn't want to sound as though I was criticising your work.
>>
>> kind regards
>> Brian
>>
>> ________________________________________
>> From: AOLserver Discussion [AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Gustaf
>> Neumann [neum...@wu-wien.ac.at]
>> Sent: 05 July 2011 23:47
>> To: AOLSERVER@LISTSERV.AOL.COM
>> Subject: Re: [AOLSERVER] Problem with file uploads larger than maxinput
>>
>> Strange, it works for me. can you send me your config file?
>> Concerning "the right place": As it was discussed here, it
>> would be certainly better to move the reply-sending to a
>> request handling thread (or a spooling thread like in
>> naviserver), simply to be sure that the driver is never
>> blocking. This should not be complicated, but i simply did
>> not have to time, and i see no reason, why replying from the
>> driver should not work.
>>
>> -gustaf
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
op.c.patch
Description: op.c.patch
tclresp.c.patch
Description: tclresp.c.patch
tclcmds.c.patch
Description: tclcmds.c.patch
