Hi
When I upload a file larger than the maxinput I get the Firefox browser page
with a the connection to the server was reset while the page was loading
message. Looking in the access logs it seems to suggest that it doesn't even
hit the website as there is no log entry. A file smaller than
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
Thanks Jim
I should have mentioned that there was nothing in the error log either.
So, how would you recommend I capture the fact that the uploaded file is larger
than our limit, and feedback to the user?
thanks
Brian
From: AOLserver Discussion
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
I think if its possible in your case use the javascript and calculate the
size of the upload file and return it right away if its exceeds the limit
this way you dont' need to worry about sending the request to the server,
waiting for a while and ended up with nothing returned.
Regards,
Majid.
Howdy,
Appears you need to set driver debug mode for the driver for the given socket
module thing:
ns_section ns/server/server1/module/nssock
ns_param debug 1
Hopefully that's not too much muck in the server log.
-Jim
On Jun 23, 2011, at 7:16 AM, Fenton, Brian wrote:
Thanks Jim
I
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
Thanks Majid
well there are Flash based on front end solutions e.g. SWFUpload, but it's not
possible in Javascript. I think it's still important to have a server solution
as well. I do agree though that it's kind of crazy to find out AFTER you upload
a file, that the file was too big!
Brian
Thanks Jim
yes that now logs the fact that the file was too big (multiple times in fact),
but how can I access this fact in TCL?
[23/Jun/2011:15:05:50][27869.163851][-nssock:driver-] Error: conn[38]: max
content exceeded
[23/Jun/2011:15:05:50][27869.163851][-nssock:driver-] Error: conn[39]:
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
line (GET /url/ ...) and headers. As it reads lines, it parses them for some
special
I'm using OpenACS hence the TCL. I just want to let the user know that their
file is over the size limit. Could we, in driver.c instead of closing the
connection socket, return a custom template (like Apache does) ?
Brian
From: AOLserver Discussion
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
Hi,
The final goal is to have a server-side validation and return a page
template explaining what the problem is rather than just closing the
connection. Having client-side validation ( JavaScript/Flash like
gmail ) helps in terms of UI but I presume wouldn't be safe enough
agains DoS.
IMHO, I
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
18 matches
Mail list logo
