Edgewall Software

Opened 17 years ago

Last modified 17 years ago

#1370 closed defect

Wiki Attachments failing with "Attachment Not Found" message as of rev. 1454 — at Version 3

Reported by: jason@… Owned by: anonymous
Priority: normal Milestone: 0.9
Component: web frontend/mod_python Version: devel
Severity: major Keywords:
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Christopher Lenz)

I'm running against svn trunk rev 1454. When attempting to create an attachment on a wiki page, I get an error message: "Attachment not found"

No traceback is visible on the webpage — I enabled file logging, and got this traceback in the log:

10:51:38 Trac[attachment] DEBUG: Trying to open attachment at /var/lib/trac/aos/attachments/wiki/SandBox
10:51:38 Trac[main] ERROR: Attachment not found
10:51:38 Trac[main] ERROR: Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/modpython_frontend.py", line 168, in handler
    dispatch_request(mpr.path_info, mpr, env)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 305, in dispatch_request
    module.render(req)
  File "/usr/lib/python2.3/site-packages/trac/attachment.py", line 63, in render
    self.render_view(req, parent_type, parent_id, filename)
  File "/usr/lib/python2.3/site-packages/trac/attachment.py", line 130, in render_view
    raise util.TracError('Attachment not found')
TracError: Attachment not found

Change History (3)

comment:1 by jason@…, 17 years ago

After some hacking around, I think I've found the solution. (it's in the attachment template). The attach form was submitting to the "current" url (<form … action="">), but that url had a paramter of "?action=new". The form itself had a hidden value of action=save (which is the correct one). The attachment code was getting both values in the action value, and was never executing the path for 'save'.

Anyway, I've updated the form action parameter, and this seems to have solved the problem. Here's a diff for what I changed:

Index: templates/attachment.cs
===================================================================
--- templates/attachment.cs     (revision 1456)
+++ templates/attachment.cs     (working copy)
@@ -9,7 +9,7 @@
 <?cs if:attachment.mode == 'new' ?>
  <h1>Add Attachment to <a href="<?cs var:attachment.parent_href?>"><?cs
    var:attachment.parent_name ?></a></h1>
- <form id="attachment" method="post" enctype="multipart/form-data" action="">
+ <form id="attachment" method="post" enctype="multipart/form-data" action="<?cs var:attachment.parent_name?>">
   <div class="field">
    <label>File:<br /><input type="file" name="attachment" /></label>
   </div>

comment:2 by Christopher Lenz <cmlenz@…>, 17 years ago

Owner: changed from Jonas Borgström to anonymous
Status: newassigned
Version: nonedevel

comment:3 by Christopher Lenz, 17 years ago

Description: modified (diff)

The problem here is that the FieldStorage implementation of mod_python behaves differently from the implementation in cgi.py. While the latter adds query-string parameters after POST body parameters, and does so only if the the parameter isn't already in the body, the mod_python implementation adds query string parameters first and unconditionally.

While the mod_python implementation is IMHO correct, cgi.py is the standard to follow. I'll attach a patch that modifies this behavior to make it compatible.

I believe this is preferrabe to hacking around the problem in the individual modules, because it decreases the probability of things failing in one frontend while working in another.

Note: See TracTickets for help on using tickets.