Brian many thanks, i commited your change to the CVS on
sourceforge.
-gustaf neumann
--
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
-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
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
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
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
: [AOLSERVER] Problem with file uploads larger than maxinput
Dear all,
As a small contribution, i added a patch to sourceforge cvs.
The patch returns the 413 error message via a new function
Ns_ConnReturnEntityToLarge(), which is written in the same
style as Ns_ConnReturnNotFound(). The patch is somewhat
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.
: 24 June 2011 08:00
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] Problem with file uploads larger than maxinput
Dear all,
As a small contribution, i added a patch to sourceforge cvs.
The patch returns the 413 error message via a new function
Ns_ConnReturnEntityToLarge(), which
A thought for an alternate way to handle this - if the content-length is
too large, the just don't read the content, but set an error flag on the
conn. That way, an adventurous system could return a custom error page,
or even handle reading the content through custom code. I think this
could
Jim Davidson wrote:
I think today, in 2011, some of the flexibility we imagined back in
1995 isn't really so needed. This includes general purpose logging
plugins and network drivers when there really is just the common log
format, ordinary and SSL sockets. More in the core for the base HTTP
Dear all,
Most of the times Aolserver is used with a reverse proxy like
Pound or Nginx in front of it. I would just leave Aolserver as it is...
and make sure that the reverse proxy checks the size of the objects to be
uploaded and provides a proper error message.
For Nginx:
server {
Dear all,
As a small contribution, i added a patch to sourceforge cvs.
The patch returns the 413 error message via a new function
Ns_ConnReturnEntityToLarge(), which is written in the same
style as Ns_ConnReturnNotFound(). The patch is somewhat
minimal and handles this issue entirely in the
Cool. The driver thread is technically a single threaded thing which shouldn't
block and the connection return functions are blocking but as the response is
small, it probably just works. Also, the connection code hasn't been verified
to run in the driver (filters, traces, etc.) but again it
Hi,
The short answer is no, there's no access log entry although there may be a
server log message buried in the chatter.
The reason is the access log is a trace that fires at the end of an HTTP
connection and the request isn't a connection until all the content has been
read and the data
IIRC, in AOLserver 4.5+, until the whole HTTP request is received by the
server, it's being handled entirely by the driver thread -- and if the
maxinput ns_limit is exceeded, the driver thread drops the connection
before it's ever dispatched to a connection thread (which might be
better
[AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Jim
Davidson [jgdavid...@mac.com]
Sent: 23 June 2011 13:47
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] Problem with file uploads larger than maxinput
Hi,
The short answer is no, there's no access log entry although there may be a
server log
Alternatively, instead of the driver thread tossing the connection on
the floor, it could mark the HTTP request as being truncated in some
way, and passing up to maxinput bytes through to the connection thread.
Then, the connection thread can decide how to handle the request -- but,
the
Brian
From: AOLserver Discussion [AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Jim
Davidson [jgdavid...@mac.com]
Sent: 23 June 2011 13:47
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] Problem with file uploads larger than maxinput
Hi
@LISTSERV.AOL.COM] On Behalf Of Jim
Davidson [jgdavid...@mac.com]
Sent: 23 June 2011 13:47
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] Problem with file uploads larger than maxinput
Hi,
The short answer is no, there's no access log entry although there may be a
server log message
I think this could work, i.e., dummy up a runt or truncated connection to
exercise the rest of the code. But, it's possible something would go
uninitialized or assume goodness, i.e., just run off the end of the truncated
content. Hmm...
I think today, in 2011, some of the flexibility we
From: AOLserver Discussion [AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Majid Khan
[majidkha...@gmail.com]
Sent: 23 June 2011 14:34
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] Problem with file uploads larger than maxinput
I think if its possible
Of Jim
Davidson [jgdavid...@mac.com]
Sent: 23 June 2011 14:44
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] Problem with file uploads larger than maxinput
Howdy,
Appears you need to set driver debug mode for the driver for the given socket
module thing:
ns_section ns/server/server1
] On Behalf Of Jim
Davidson [jgdavid...@mac.com]
Sent: 23 June 2011 14:44
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] Problem with file uploads larger than maxinput
Howdy,
Appears you need to set driver debug mode for the driver for the given
socket module thing
[AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Jim
Davidson [jgdavid...@mac.com]
Sent: 23 June 2011 15:59
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] Problem with file uploads larger than maxinput
I think the short answer is there is no way.
Checking the code and your error message
Yes, on E_CRANGE, the driver thread should return HTTP 413 Request too
large, IMHO. And, we should be able to configure a custom response for
status code 413 ...
Patches welcome ;)
On 6/23/11 11:28 AM, Fenton, Brian wrote:
I'm using OpenACS hence the TCL. I just want to let the user know
Agreed. Should go on the bug/feature list. Is there a list ? :)
Sent from a phone
On Jun 23, 2011, at 9:58 AM, Dossy Shiobara do...@panoptic.com wrote:
Yes, on E_CRANGE, the driver thread should return HTTP 413 Request too large,
IMHO. And, we should be able to configure a custom response
@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] Problem with file uploads larger than maxinput
I think the short answer is there is no way.
Checking the code and your error message, this is error condition E_CRANGE.
It's returned from SockReadLine which is called repeatedly to read the
request
In theory, it could go on SourceForge's issue tracker ... or opened as a
issue on GitHub ... or ...
On 6/23/11 12:13 PM, Jim Davidson wrote:
Agreed. Should go on the bug/feature list. Is there a list ? :)
Sent from a phone
On Jun 23, 2011, at 9:58 AM, Dossy Shiobarado...@panoptic.com
That was what I was thinking -- driver marks the request as exceeding
the limit, and setting the response status code to 413. The benefits
that I see (if implemented the way I'm imagining) --
1) access logging of requests w/ 413 status code
2) custom response page via
I think this one case can be handled this way because you could truncate the
request (some content may have been read ahead) and then flag it for special
handling in the normal connection processing code/threads. The reason is the
server has a full request, you're just choosing to not read all
30 matches
Mail list logo
