Upload of documents and images and fails on server?
778 views
Skip to first unread message
Bob Wentworth
Apr 9, 2016, 5:20:04 PM4/9/16
to Wagtail support
Uploading of Images or Documents does not work on our server. (It works on the laptop I'm using for development). The Wagtail admin interface simply reports "Sorry, upload failed" -- which doesn't provide much to go on.
- I have verified that the application can successfully write files to the media folder and its subfolders, so it doesn't seem to be a directory permission problem.
- The problem has occurred with a .jpg image, a .png image, and a .txt document.
Any ideas about where the problem might be, or how to approach debugging this?
* * * * *
As an odd side note, the behavior the first time I encountered the image upload problem differed from the behavior all subsequent times. Similarly for the first time I encountered the document upload problem. Restarting the server doesn't cause the "first time only" behavior to reappear.
I don't recall the first-time Image upload error behavior, just that it was different.
For the document upload, the first-time behavior was to report an exception because a template could not be found (running with DEBUG=True since we're not public yet).
The subsequent-time error behavior is to show the upload progress bar ramp up to 100 percent, then say "Sorry, upload failed."
Any clue why the first-time behavior might have been different?
* * * * *
I'm finding this puzzling. Any clues would be appreciate.
Bob
Message has been deleted
Message has been deleted
Bob Wentworth
Apr 9, 2016, 9:03:53 PM4/9/16
to Wagtail support
The actual first-time error associated with the first document up-load attempt was:
Page not found (404)
| Request Method: | POST |
|---|---|
| Request URL: | http://staging.nwcompass.org/admin/documents/add/ |
| Raised by: | wagtail.wagtailadmin.decorators.decorated_view |
Bob Wentworth
Apr 10, 2016, 2:45:18 AM4/10/16
to Wagtail support
Well, I've narrowed it down... when uploading a document, the POST request gets to Django, but somehow doesn't get to wagtail.wagtaildocs.views.multiple's add() method. So, something is off with request routing...
(The preceding GET request to the same method works, and POST requests for other administrative actions work as expected.)
Bob Wentworth
Apr 11, 2016, 1:00:10 AM4/11/16
to Wagtail support
Why would Django dispatch a POST request to a different end point than for a GET request? (And only on our server, not on my laptop?)
Further incremental progress... as viewed from the level of Django middleware, there definitely seems to be a dispatching anomaly...
Requests to URL /admin/documents/multiple/add/ are normally routed to an add() function in wagtail.wagtaildocs.views.multiple (albeit this function is wrapped in a couple of layers of decorators). This happens consistently in my development environment, and on our server, it happens for the initial GET request. However, on the server, for the POST request associated with saving the uploaded document, the request to this same URL instead gets routed to function server() in wagtail.wagtailcore.views, which doesn't know how to deal with the request and returns a 404/not found response. So, the POST request is being sent to a different endpoint than is the GET request, on our server, but not on my laptop.
I have yet to determine how this could possibly be happening. As always, any insights others might have would be welcome.
(Configuration info: The django-extensions show_urls command claims that the URL settings are identical in the two different environments where the behaviors differ. Django 1.9.5, Wagtail 1.4.3, all packages same versions in both environments. Python 2.7.10 on OS X laptop and 2.7.11 on Linux server.)
Further incremental progress... as viewed from the level of Django middleware, there definitely seems to be a dispatching anomaly...
Requests to URL /admin/documents/multiple/add/ are normally routed to an add() function in wagtail.wagtaildocs.views.multiple (albeit this function is wrapped in a couple of layers of decorators). This happens consistently in my development environment, and on our server, it happens for the initial GET request. However, on the server, for the POST request associated with saving the uploaded document, the request to this same URL instead gets routed to function server() in wagtail.wagtailcore.views, which doesn't know how to deal with the request and returns a 404/not found response. So, the POST request is being sent to a different endpoint than is the GET request, on our server, but not on my laptop.
I have yet to determine how this could possibly be happening. As always, any insights others might have would be welcome.
(Configuration info: The django-extensions show_urls command claims that the URL settings are identical in the two different environments where the behaviors differ. Django 1.9.5, Wagtail 1.4.3, all packages same versions in both environments. Python 2.7.10 on OS X laptop and 2.7.11 on Linux server.)
Bob Wentworth
Apr 11, 2016, 3:23:21 AM4/11/16
to Wagtail support
In case it might be of help to anyone else, the problem has been isolated. The problem is some incorrect behavior on the part of the web server (or the CloudLinux / Phusion Passenger software that it uses to service a WSGI interface).
- For a GET request to /admin/documents/multiple/add/ our application receives SCRIPT_NAME=“” (or maybe “/“) and PATH_INFO="/admin/documents/multiple/add/“, as expected.
- For a multipart POST request to the same URL, /admin/documents/multiple/add/, our application receives SCRIPT_NAME=“/admin” and PATH_INFO="/documents/multiple/add/“ — which is incorrect.
Because Django resolves URLs based on PATH_INFO, this was breaking the Wagtail image/document upload features.
Niklas Bergh
May 22, 2017, 6:05:51 PM5/22/17
to Wagtail support
Hi,
Im having the same problem on a production server. Did you figure out a solution in this matter?
Regards,
Niklas
Reply all
Reply to author
Forward
0 new messages