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.