In my view I generate 5 images (they are generated by pyplot.)
Everything seems to work fine. The files are generated correctly in the right directory.
But the browser only shows one of the five images, and the requests for the other 4 usually timeout. Looking at the django server output, the GET requests will often take five minutes to finish.
These images are ~100kb, and are present and correct on the drive immediately after being generated.
Am I missing a call for Django to update the new static files? Something else? Please help!
Deal with them as a media file, save the files to your media server (CDN or local), then send the URL of the images to the browser to load them.
I also faced a similar problem but with audio files. To resolve that issue I used pagination and that solved my issue. I think you should try that, like view one image in one page and second image on second page.
Related
I want to upload some files to sharepoint via office365 REST Python client.
On documentation on github, I found two examples:
one for larger files where this is executed:
uploaded_file = target_folder.files.create_upload_session(local_path, size_chunk, print_upload_progress).execute_query()
one for small files :
target_file = target_folder.upload_file(name, file_content).execute_query() .
In my case, I want to be able to upload files who are small and also files who are very large.
For testing, I wanted to see if the method for larger files works with smaller files too.
With a small file, while putting the size_chunk at 1Mb, the uploading was done, but the file uploaded was empty (0b), so I lost my content while uploading.
I wanted to know if there is someone who knows how can we do something more generic for whatever size of files. Also I don't understand what is the size chunk for larger files case. Do you know how one should choose it?
Thank you so much!
This problem is solved by installing office365-rest-python-client instead of office365-rest-client.
First of all, I must say I have seen something similar to this in the web2py discussion group, but I couldn't understand it very well.
I've set up a database-driven website using web2py in which the entries are just HTML text. Most of them will contain img and/or video tags that point to relative URLs; these files are stored in folders with the address pattern static/content/article/<article-name> and the document's base href is set via the controller to make these links work. So, the images are stored and referenced directly, without all the upload/download machinery.
I'm testing it locally and using Rocket server because I'm not allowed to install Apache in this PC.
The problem:
Everything works fine, except, as it seems, when there are several "large" files being requested. By "large" I mean 4Mb files were enough, which isn't really a lot (and I think slightly smaller files would produce the same result). I'm pretty sure the links aren't broken since 1) by copying/pasting their URLs in the browser they show up normally, 2) the images/videos appear well/broken randomly when I refresh the page and 3) sometimes a video loads until a certain point and then stops, and the browser inspector shows a 'fail' signal. When I replaced these files with smaller ones (each with a dozen kb), all of them loaded. Another thing to consider is that sometimes it takes a really long time until the page finishes loading (from 2 seconds to several minutes).
The questions:
Is this the simplest/optimal way of getting the job done? I'm aware that web2py has some neat features like upload fields, but I don't know how I could make these files be effortlessly referenced in the document, considering there will be some special features in such pages involving the static files. So the solution I've come up with so far was to create a directory which name equals to the entry's and store the files there, as I said before. Is it an overkill considering what web2py has to offer?
If the answer to the first question is something like "yes", then (obvious question) what may be causing the problem and how do I fix it? Does it have something to do with the fact that web2py sends static files in chunks of 1Mb? Might it be the Rocket server? Or because I'm testing it locally?
Thanks in advance!
It's hard to give you an answer without knowing some details...
Where is hosted your Web2py application?
Do you use apache? nginx?
Did you deploy using a one step-deploy script? (http://web2py.googlecode.com/hg/scripts/setup-web2py-ubuntu.sh)
But in any case, you can (should) :
Configure Apache/Nginx to serve your static files directly (files in /YourApp/static/.). See "setup-web2py-" scripts in the "scripts" folder for more informations
Use scripts/zip_static_files.py to create gzipped versions of your static files. You can create a cron to run "python web2py.py -S myapp -R scripts/zip_static_files.py"
More details about efficiency in the book : http://web2py.com/books/default/chapter/29/13/deployment-recipes?search=static+files#Efficiency-and-scalability
You can upload an individual file with the Admin site. However I have a need to upload at least 1 file, but potentially multiple files, for each object. Sometimes there will be sub-directories with these files that must also be uploaded.
Is there a good way to do this in the Admin site? Or would you recommend simply sftp-ing the files across and storing the path to them?
Thank you for your help.
I've only very recently starting working with Django, so do not yet know all the cool features I could be using :-)
Maybe have a look at https://github.com/stefanfoulis/django-filer, it allows multiple files to be uploaded at once.
I want to serve images in a web-app using sessions such that the links to the images expire once the session has expired.
If I show the actual links to the filesystem store of the images, say http://www.mywebapp.com/images/foo1.jpg this clearly makes stopping future requests for the image (one the user has signed out of the session) difficult to stop. Which is why I was considering placing the images in a sqlite db, and serving them from there.
It seems that using the db for image storage is considered bad practice (though apparently the GAE blob store seems to provide this functionality), so i was trying to figure out what the alternatives would be.
1)
Perhaps I do somesort of url-re-writing like so:
http://www.mywebapp.com/images/[session_id]/foo1.jpg
Thinking of using nginx, but it seems (on a first look) that this will require some hackin to accomplish?
2)
Copy the files to a physical directory on the filesystem and delete when the session expires. this seems quite messy though?
Are there any standard methods of accomplishing this dynamic image url thing?
I'm using web.py - if that helps.
Many thanks!
lighty's mod_secdownload has worked well for me to solve this issue. You can read more about it at http://redmine.lighttpd.net/wiki/1/Docs:ModSecDownload
The lighttpd wiki also has a generic article about your problem: http://redmine.lighttpd.net/wiki/1/HowToFightDeepLinking
Why so complicated?
Serve the image under the name which the user supplied (i.e. http://www.mywebapp.com/images/foo1.jpg)
Save the images in a directory using a UUID as name.
Create a map of file names to UUIDs in the session.
In the handler for /images/ look up the real file name in the map. Return 404 if no such entry exists. Otherwise serve the image.
When the session is closed, delete all files from the map.
In a cron job, delete all images that are older than one day.
This way, several users can upload the same image (same name), images get deleted as soon as possible or by the cron job (if the server crashes or something like that).
A combination of your two ideas (copy to a dir, expire when session expires) could be generalized to creating a new dir (could be as simple as a symlink) every 15 minutes. When generating the new symlink, also remove the one that's an hour old by now. Always link to the newest name in your code.
So ive just started learning python on WAMP, ive got the results of a html form using cgi, and successfully performed a database search with mysqldb. I can return the results to a page that ends with .py by using print statements in the python cgi code, but i want to create a webpage that's .html and have that returned to the user, and/or keep them on the same webaddress when the database search results return.
thanks
paul
edit: to clarify on my local machine, i see /localhost/search.html in the address bar i submit the html form, and receive a results page at /localhost/cgi-bin/searchresults.py. i want to see the results on /localhost/results.html or /localhost/search.html. if this was on a public server im ASSUMING it would return .../cgi-bin/searchresults.py, the last time i saw /cgi-bin/ directories was in the 90s in a url. ive glanced at addhandler, as david suggested, im not sure if thats what i want.
edit: thanks all of you for your input, yep without using frameworks, mod_rewrite seems the way to go, but having looked at that, I decided to save myself the trouble and go with django with mod_wsgi, mainly because of the size of its userbase and amount of docs. i might switch to a lighter/more customisable framework, once ive got the basics
First, I'd suggest that you remember that URLs are URLs and that file extensions don't matter, and that you should just leave it.
If that isn't enough, then remember that URLs are URLs and that file extensions don't matter — and configure Apache to use a different rule to determine that is a CGI program rather than a static file to be served up as is. You can use AddHandler to add a handler for files on the hard disk with a .html extension.
Alternatively, you could use mod_rewrite to tell Apache that …/foo.html means …/foo.py
Finally, I'd suggest that if you do muck around with what URLs look like, that you remove any sign of something that looks like a file extension (so that …/foo is requested rather then …/foo.anything).
As for keeping the user on the same address for results as for the request … that is just a matter of having the program output the basic page without results if it doesn't get the query string parameters that indicate a search term had been passed.