RE: [otrs] Re: Attaching large files via Customer web interface.

You're quite right. The httpd daemon should not crash as a result - but in any case, it could give rather strange results. In the cases i've seen and tested, IE would return a DNS error - which if course had nothing to do with it. But anyway, I suggest you bump up the error logging on Apache and see if that can give you any clues. thomas -----Original Message----- From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Dave Hill Sent: Wednesday, March 01, 2006 11:42 AM To: otrs@otrs.org Subject: [otrs] Re: Attaching large files via Customer web interface. Hi Thomas, no, there is no limit in the httpd config files that I can find. Also, if there was such a limit, surely some sort of error would occur rather than the daemon committing suicide? I'll do some more playing around, I'll try setting that variable and see if I at least get a sensible error message. Also I'll try restricting the size in OTRS similarly. We don't really *want* people to attach large documents, but we *do* want it to fail gracefully and not DoS the server! Dave -- Dave Hill Newnham Research Ltd _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support oder Consulting für Ihr OTRS System? => http://www.otrs.de/ DISCLAIMER: This message contains information that may be privileged or confidential and is the property of the Roxar Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorised to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

In article
<3D8D97FDA7A52F4CB773EF3BBA9470D3106924@svgw2k15.roxardomain.roxar.com>,
"Thomas Nilsen"
You're quite right. The httpd daemon should not crash as a result - but in any case, it could give rather strange results. In the cases i've seen and tested, IE would return a DNS error - which if course had nothing to do with it. But anyway, I suggest you bump up the error logging on Apache and see if that can give you any clues.
thomas
Initial testing: I reduced the $Self->{WebMaxFileUpload} setting in OTRS from 5Mb to 4Mb. Now the http daemon thrashes and is killed when I try to attach the 4.8Mb document. This variable seems to be only used to set the value of $CGI::POST_MAX in Kernel/System/Web/Request.pm - time for some more Googling! Dave -- Dave Hill Newnham Research Ltd

In article
In article <3D8D97FDA7A52F4CB773EF3BBA9470D3106924@svgw2k15.roxardomain.roxar.com>, "Thomas Nilsen"
wrote: You're quite right. The httpd daemon should not crash as a result - but in any case, it could give rather strange results. In the cases i've seen and tested, IE would return a DNS error - which if course had nothing to do with it. But anyway, I suggest you bump up the error logging on Apache and see if that can give you any clues.
thomas
Initial testing: I reduced the $Self->{WebMaxFileUpload} setting in OTRS from 5Mb to 4Mb. Now the http daemon thrashes and is killed when I try to attach the 4.8Mb document.
This variable seems to be only used to set the value of $CGI::POST_MAX in Kernel/System/Web/Request.pm - time for some more Googling!
Googling for $CGI::POST_MAX brings up a number of similar occurrences which are nothing to to with OTRS. This URL http://www.codecomments.com/message162736.html details the problem, which occurs in CGI.pm version 3.0 and higher - it also has a diff of the allegedly offending code. I tried backing out the code in CGI.pm and the apache daemon no longer consumes all the memory and gets killed, but the user just eventually gets a "Couldn't connect to server" error rather than a sane error message about file size restrictions. Further poking in OTRS reveals that although an error routine exists in Request.pm, I can't seem to find where it is called! Dave -- Dave Hill Newnham Research Ltd
participants (2)
-
Dave Hill
-
Thomas Nilsen