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
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 ns/server/${server}/redi
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 Shiobara wrote:
> Yes, on E_C
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
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 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 for status code
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 th
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 [AOLS
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 condit
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]: max
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
_
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
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 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.
O
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 driver
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 [AOLSE
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 refer
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
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 t
18 matches
Mail list logo