Ticket attachments fail even when max_size set to -1

[klktrk]

Hello,

I am trying to attach files to a ticket. When I do so, I get the
following error in my browser
Request Entity Too Large
The requested resource
/attachment/ticket/1/
does not allow request data with POST requests, or the amount of data
provided in the request exceeds the capacity limit.

I am able to attach files that are *very* small (under 100k).

I am running trac 0.11.5 on Debian etch, installed with easy_install

Here are my settings:
trac.ini
[attachment]
max_size = -1

trac.conf (virtual server conf)
LimitRequestBody 536870911

I am able to upload large files via PHP and other apps, so I doubt its
my apache server.

Is this a bug in this version?

[Cooke, Mark]

Hello,

> I am trying to attach files to a ticket. When I do so, I get the
> following error in my browser
> Request Entity Too Large
> The requested resource
> /attachment/ticket/1/
> does not allow request data with POST requests, or the amount of data
> provided in the request exceeds the capacity limit.
>
> I am able to attach files that are *very* small (under 100k).
>
> I am running trac 0.11.5 on Debian etch, installed with easy_install
>
> Here are my settings:
> trac.ini
> [attachment]
> max_size = -1
>

I am not sure if '-1' is a valid value (and it does not seem to be
mentioned as an option or in the wiki), so try setting a real value
larger than your attachment, restart trac then try to upload again...

~ mark c

[klktrk]

Just an update. -1 *is* a documented value (for unlimited).

I have since found the real issue. I am using mod_security, with a
rule-set that limits inbound requests.

What's interesting is since I've posted this, I've come across lots of
behaviors in trac that mod_security's generic ruleset is choking on
(for example multipart unmatched boundaries). I may write them up here
since it might encourage better app dev practices in the future.

Thank you for taking the time to reply. The takeaway: check
mod_security, if you're running it.

[RAAFET DORMOK]

Make that:


[attachment]
max_size = 500000
render_unsafe_content = false





-----Message d'origine-----
De : klktrk [mailto:mindless...@gmail.com]
Envoyé : vendredi 20 novembre 2009 04:35
À : Trac Users
Objet : [Trac] Ticket attachments fail even when max_size set to -1

--

You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-users?hl=.

[klktrk]

In the end, I filed the following bug report: http://trac.edgewall.org/ticket/8849

Thanks for your input, all.

[klktrk]

On Nov 20, 2:17 am, "RAAFET DORMOK" <raafet.dor...@biat.com.tn> wrote:
> Make that:
>
> [attachment]
> max_size = 500000
> render_unsafe_content = false

The render_unsafe_content didn't actually help with mod_security. The
only way to bypass was this:
In my modsecurity.conf, I added an id value to the following rule:
# Did we see anything that might be a boundary?
#SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"phase:2,t:none,log,deny,msg:'Multipart parser detected a possible
unmatched boundary.'"

So it looks like this now:
# give this rule an id, so we can make an exception
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"phase:2,t:none,log,deny,msg:'Multipart parser detected a possible
unmatched boundary.',id:111"


In my website virtual host file:
<IfModule mod_security2.c>
# bigger uploads
SecRequestBodyLimit 10240000
# see line 64 of modsecurity.conf
SecRuleRemoveById 111
</IfModule>

This allowed me to disable the checking for an unmatched boundary just
for my trac virtual host, and not the others. It does seem that this
shouldn't have to be done, and that multipart uploads/attachments in
trac should be sent in such a way that they don't have an unmatched
boundary. IE, I am running several other full-featured web apps on my
other virtual hosts (drupal, wordpress etc), and have never had to
modify my default mod_security rules to make them work.

Is there something I'm missing, or should I file a bug/enhancement?