So i have setup parse-server, specifically parse-server-example on Heroku with mLab db and s3 file adapter for storage.
Ive been scouring GitHub and stack overflow trying to find a solution to the maxUploadSize limitations.
By default this is set to '20mb' and sources say that you can modify this option to be anything you like. Within my parse-server-example there are 4 files that contain this variable:
1. ParseServer.js
/parse-server-example/node_modules/parse-server/lib
2. FilesRouter.js
/parse-server-example/node_modules/parse-server/lib/Routers
3.parse-server.js
/parse-server-example/node_modules/parse-server/lib/cli/definitions
3. index.js
/parse-server-example
4. defaults.js
/parse-server-example/node_modules/parse-server/lib
I have replaced all instances of '20mb' with '100mb' in these 4 files and have added the maxUploadSize option variable to my index.js file. I think the only place where this matters is the index.js file. This is where i changed it originally and it did allow larger files, i then changed it in the other locations out of desperation and there has been no change in the result.
index.js:
var api = new ParseServer({
//**** General Settings ****//
databaseURI: databaseUri || 'mongodb://localhost:27017/dev',
cloud: process.env.CLOUD_CODE_MAIN || __dirname + '/cloud/main.js',
serverURL: process.env.SERVER_URL || 'http://localhost:1337/parse',
maxUploadSize: '100mb',
Now i can upload files upto 40mb quite easily, but when i try upload anything larger it shows as uploading in the dashboard for quite a while then just stops.
I have also read that setting the client_max_body_size in .ebextensions may play a part but i think this is for elastic beanstalk on aws so don't think its relevant for me. Though i even tried adding the variable in a files.config file inside the .ebextensions folder in my /parse-server-example/ folder.
I am uploading files through the parse dashboard so they are then transferred to the s3bucket i have setup with the unique PFFIle name.
This is what my Heroku logs look like after trying a 50mb upload:
2017-02-06T06:58:14.188932+00:00 app[web.1]: } method=POST, url=/parse/classes/Part, host=parse-server-example.herokuapp.com, connection=close, content-type=text/plain, origin=http://0.0.0.0:4040, accept-encoding=gzip, deflate, accept=*/*, user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/602.3.12 (KHTML, like Gecko) Version/10.0.2 Safari/602.3.12, referer=http://0.0.0.0:4040/apps/parse-server-example/browser/Part, accept-language=en-au, x-request-id=df8ecd66-76f5-4592-9c82-44a86f6c4165, x-forwarded-for=101.165.231.37, x-forwarded-proto=https, x-forwarded-port=443, via=1.1 vegur, connect-time=1, x-request-start=1486364292657, total-route-time=0, content-length=235, __op=Delete
2017-02-06T06:58:14.210449+00:00 app[web.1]: [36mverbose[39m: RESPONSE from [POST] /parse/classes/Part: {
2017-02-06T06:58:14.210451+00:00 app[web.1]: "status": 201,
2017-02-06T06:58:14.210452+00:00 app[web.1]: "response": {
2017-02-06T06:58:14.210453+00:00 app[web.1]: "objectId": "vrIuYJCOfG",
2017-02-06T06:58:14.210455+00:00 app[web.1]: "createdAt": "2017-02-06T06:58:14.190Z"
2017-02-06T06:58:14.210456+00:00 app[web.1]: },
2017-02-06T06:58:14.210457+00:00 app[web.1]: "location": "https://parse-server-example.herokuapp.com/parse/classes/Part/vrIuYJCOfG"
2017-02-06T06:58:14.210459+00:00 app[web.1]: } status=201, objectId=vrIuYJCOfG, createdAt=2017-02-06T06:58:14.190Z, location=https://parse-server-example.herokuapp.com/parse/classes/Part/vrIuYJCOfG
2017-02-06T06:58:29.061410+00:00 heroku[router]: at=info method=OPTIONS path="/parse/files/South%20Park%20s09e02%20-%20Die%20Hippie,%20Die%20_%20480p%20UNCENSORED%20x264%20NIT158.mp4" host=parse-server-example.herokuapp.com request_id=0e76d848-3c8a-44e5-8efe-4d586ced8e8a fwd="111.111.111.11" dyno=web.1 connect=0ms service=1ms status=200 bytes=477
It seems to show everything as bytes=447 regardless of actual size?
There is another version of parse-server on GitHub that has a different FilesRouter.js file and others but they look to be the development master.
I am wondering if it may be advised to overwrite my existing setup with this one, if so how to do it without stuffing up what I've done so far? or even if this will fix the problem??
Is it something to do with the dashboard? I have not found another way to upload files and have them linked to the s3 bucket.
I should also add that i don't want users to upload files, this is just me attempting to populate the app with some media files that can be downloaded.
Thanks for any assistance here, this one has been a struggle for me to figure out despite looking for a long long time now.
Seems like my IP's abysmal upload speed is responsible for this.
gone back through and cleaned up my changes. The index.js is the only place that you need to set the maxUploadSize variable.
Related
I deployed a rails 6 app with webpacker on heroku.
The public/packs are sync to an s3 bucket, same as the public/assets.
Delivering assets from public/assets works. But when trying to open anything dependent on public/packs I get.
2020-06-04T05:33:03.622234+00:00 app[web.1]: [58f2d221-761b-44ec-807c-6b922342c10b] method=GET path=/teach/organizations format=html controller=OrganizationsController action=index status=500 error='ActionView::Template::Error: Webpacker can't find admin_unify_style.css in /app/public/packs/manifest.json. Possible causes:
2020-06-04T05:33:03.622242+00:00 app[web.1]: 1. You want to set webpacker.yml value of compile to true for your environment
2020-06-04T05:33:03.622242+00:00 app[web.1]: unless you are using the `webpack -w` or the webpack-dev-server.
2020-06-04T05:33:03.622243+00:00 app[web.1]: 2. webpack has not yet re-run to reflect updates.
2020-06-04T05:33:03.622243+00:00 app[web.1]: 3. You have misconfigured Webpacker's config/webpacker.yml file.
2020-06-04T05:33:03.622244+00:00 app[web.1]: 4. Your webpack configuration is not creating a manifest.
2020-06-04T05:33:03.622244+00:00 app[web.1]: Your manifest contains:
2020-06-04T05:33:03.622245+00:00 app[web.1]: {
2020-06-04T05:33:03.622245+00:00 app[web.1]: }
How is heroku expected to find about the manifest on heroku. The manifest contains
"entrypoints": {
"admin_unify_style": {
"css": [
"/packs/css/admin_unify_style-c2ad729a.css"
],
"js": [
"/packs/js/admin_unify_style-62270c86710162620f91.js"
],
"js.map": [
"/packs/js/admin_unify_style-62270c86710162620f91.js.map"
]
Update 1:
It is working in production env outside of heroku and without assets on cloudfront
Long story short - the manifest should be on heroku, while the assets could be on s3
Here is how I got it working - Heroku, S3, Cloudfront, Webpacker, Rails 6, Sprockets.
Assets are precompiled and uploaded to s3. public/assets and public/packs are ignored from the repo.
public/assets/*
!public/assets/.sprockets-manifest*
public/packs/*
!public/packs/manifest.json*
But as you could see the manifest are not.
Cloudfront is configured for production with
config.action_controller.asset_host = "https://blabla.cloudfront.net"
public/assets and public/fonts are synced on s3 with a s3cmd command. Custom script.
After the are synced to s3 we are commiting the manifests
if git ls-files -m | grep "public/assets/.sprockets-manifest\|public/packs/manifest.json*"; then
git add --all public/assets/.sprockets-manifest* -f
git add --all public/packs/manifest.json* -f
git commit -m "Autocompiling assets from jenkins"
git push
fi
In this way we only have the two manifests in the repo with all the assets on S3.
5. Push to heroku and it works. For now, like charm
First-time poster, I tried to follow the rules but please tell me if anything is missing and/or needs to be edited in this question.
TL;DR : using ActiveStorage, pictures associated to items display fine on localhost but not on Heroku
Initial setup
In an educational context, my team and I are building a simple Ruby On Rails application. We have to use Ruby 2.5.1 and Rails 5.2.4 with a postgresql 9.5 database in development, and we have to use Heroku for production.
The source code is hosted on a GitLab instance name Framagit. We are using the GitLab pipeline to deploy the code to Heroku everytime a merge is completed in the staging branch.
Procfile is as follows :
realease: rails db:migrate && rails db:seed
web: rails server
On this app, the main model is Compost. Each instance has one picture. These pictures are stored under :
app/assets/images/compost_pictures/compost_{001-007}.jpg
ActiveStorage setup
ActiveStorage has been installed by running $ rails active_storage:install followed by $ rails db:migrate which created the active_storage_attachments and active_storage_blobs tables in db/schema.rb.
app/models/compost.rb was updated with :
# Active Storage picture association
has_one_attached :picture
app/views/composts/show.html.erb now includes :
<div class="col-8">
<% if #compost.picture.attached? %>
<%= image_tag #compost.picture, style:"height: auto; max-width:100%" %>
<% else %>
<h3> Hey, why don't you provide a nice compost picture ?</h3>
<% end %>
</div>
(also tried with image_tag url_for(#compost.picture) with no success on Heroku, although it works on localhost)
(#compost is set in the controller and works fine for other composts attributes display)
and db/seeds.rb was updated with :
def compost_seed(user)
new_compost = user.owned_composts.create!( all the attributes...)
picture_file_name = 'compost_' + (format '%03d', rand(1..7)) + '.jpg'
picture_path = Rails.root.join("app", "assets", "images", "compost_pictures", picture_file_name)
new_compost.picture.attach(
io: File.open(picture_path),
filename: picture_file_name,
content_type: "image/jpg"
)
end
Running the server
Locally
On localhost with the Rails server set to development, everything works fine, pictures are displayed.
I've set up a simulated production environment like this :
$ RAILS_ENV=production rails db:create db:migrate
# completed with no error
$ RAILS_ENV=production rails assets:precompile
# completed with no error
$ RAILS_ENV=production rails db:seed
# completed with no error
$ RAILS_ENV=production SERVE_STATIC_ASSETS=true rails server
# server runs smoothly
Everything works fine, pictures are displayed.
On Heroku
none of the pictures is displayed : they are replaced by a broken image symbol
when in Heroku rails console, > Compost.all.sample.picture.attached? returns true
in the browser, the URL of the image is https://ok-compost-staging.herokuapp.com/rails/active_storage/disk/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaDdDRG9JYTJWNVNTSWRaV2huZW1SRGVESkRTRE5sWWxoSGJYSlJSakpTVG5OVUJqb0dSVlE2RUdScGMzQnZjMmwwYVc5dVNTSkphVzVzYVc1bE95Qm1hV3hsYm1GdFpUMGlZMjl0Y0c5emRGOHdNRFl1YW5Cbklqc2dabWxzWlc1aGJXVXFQVlZVUmkwNEp5ZGpiMjF3YjNOMFh6QXdOaTVxY0djR093WlVPaEZqYjI1MFpXNTBYM1I1Y0dWSklnOXBiV0ZuWlM5cWNHVm5CanNHVkE9PSIsImV4cCI6IjIwMTktMTItMDdUMDA6NDM6NTUuNTYzWiIsInB1ciI6ImJsb2Jfa2V5In19--ee616a99d031d361f2b63aeb869ca5d787ef44a8/compost_006.jpg?content_type=image%2Fjpeg&disposition=inline%3B+filename%3D%22compost_006.jpg%22%3B+filename%2A%3DUTF-8%27%27compost_006.jpg and trying to visit it ends up with a 'We're sorry, but something went wrong'.
The logs are :
2019-12-07T00:44:44.433822+00:00 heroku[router]: at=info method=GET path="/rails/active_storage/disk/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaDdDRG9JYTJWNVNTSWRVMVI1ZERoQ1ZXUlFibUpTTVZGNFRWbEVUamhaVldsMkJqb0dSVlE2RUdScGMzQnZjMmwwYVc5dVNTSkphVzVzYVc1bE95Qm1hV3hsYm1GdFpUMGlZMjl0Y0c5emRGOHdNREV1YW5Cbklqc2dabWxzWlc1aGJXVXFQVlZVUmkwNEp5ZGpiMjF3YjNOMFh6QXdNUzVxY0djR093WlVPaEZqYjI1MFpXNTBYM1I1Y0dWSklnOXBiV0ZuWlM5cWNHVm5CanNHVkE9PSIsImV4cCI6IjIwMTktMTItMDdUMDA6NDk6MzcuMzI2WiIsInB1ciI6ImJsb2Jfa2V5In19--cae4ff5349cfa4a394c081da5827f0c35ce96c08/compost_001.jpg?content_type=image%2Fjpeg&disposition=inline%3B+filename%3D%22compost_001.jpg%22%3B+filename%2A%3DUTF-8%27%27compost_001.jpg" host=ok-compost-staging.herokuapp.com request_id=e8ca9a03-07c4-459d-ab20-4e096da30e87 fwd="78.201.127.110" dyno=web.1 connect=0ms service=4ms status=500 bytes=1827 protocol=https
2019-12-07T00:44:47.277080+00:00 app[web.1]: I, [2019-12-07T00:44:47.276974 #4] INFO -- : [f8400596-5b61-4569-ad22-b514afe4b32a] Started GET "/rails/active_storage/disk/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaDdDRG9JYTJWNVNTSWRVMVI1ZERoQ1ZXUlFibUpTTVZGNFRWbEVUamhaVldsMkJqb0dSVlE2RUdScGMzQnZjMmwwYVc5dVNTSkphVzVzYVc1bE95Qm1hV3hsYm1GdFpUMGlZMjl0Y0c5emRGOHdNREV1YW5Cbklqc2dabWxzWlc1aGJXVXFQVlZVUmkwNEp5ZGpiMjF3YjNOMFh6QXdNUzVxY0djR093WlVPaEZqYjI1MFpXNTBYM1I1Y0dWSklnOXBiV0ZuWlM5cWNHVm5CanNHVkE9PSIsImV4cCI6IjIwMTktMTItMDdUMDA6NDk6MzcuMzI2WiIsInB1ciI6ImJsb2Jfa2V5In19--cae4ff5349cfa4a394c081da5827f0c35ce96c08/compost_001.jpg?content_type=image%2Fjpeg&disposition=inline%3B+filename%3D%22compost_001.jpg%22%3B+filename%2A%3DUTF-8%27%27compost_001.jpg" for 78.201.127.110 at 2019-12-07 00:44:47 +0000
2019-12-07T00:44:47.277980+00:00 app[web.1]: I, [2019-12-07T00:44:47.277897 #4] INFO -- : [f8400596-5b61-4569-ad22-b514afe4b32a] Processing by ActiveStorage::DiskController#show as JPEG
2019-12-07T00:44:47.278103+00:00 app[web.1]: I, [2019-12-07T00:44:47.278010 #4] INFO -- : [f8400596-5b61-4569-ad22-b514afe4b32a] Parameters: {"content_type"=>"image/jpeg", "disposition"=>"inline; filename=\"compost_001.jpg\"; filename*=UTF-8''compost_001.jpg", "encoded_key"=>"eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaDdDRG9JYTJWNVNTSWRVMVI1ZERoQ1ZXUlFibUpTTVZGNFRWbEVUamhaVldsMkJqb0dSVlE2RUdScGMzQnZjMmwwYVc5dVNTSkphVzVzYVc1bE95Qm1hV3hsYm1GdFpUMGlZMjl0Y0c5emRGOHdNREV1YW5Cbklqc2dabWxzWlc1aGJXVXFQVlZVUmkwNEp5ZGpiMjF3YjNOMFh6QXdNUzVxY0djR093WlVPaEZqYjI1MFpXNTBYM1I1Y0dWSklnOXBiV0ZuWlM5cWNHVm5CanNHVkE9PSIsImV4cCI6IjIwMTktMTItMDdUMDA6NDk6MzcuMzI2WiIsInB1ciI6ImJsb2Jfa2V5In19--cae4ff5349cfa4a394c081da5827f0c35ce96c08", "filename"=>"compost_001"}
2019-12-07T00:44:47.279105+00:00 app[web.1]: I, [2019-12-07T00:44:47.279040 #4] INFO -- : [f8400596-5b61-4569-ad22-b514afe4b32a] Completed 500 Internal Server Error in 1ms (ActiveRecord: 0.0ms)
2019-12-07T00:44:47.279772+00:00 app[web.1]: F, [2019-12-07T00:44:47.279702 #4] FATAL -- : [f8400596-5b61-4569-ad22-b514afe4b32a]
2019-12-07T00:44:47.279842+00:00 app[web.1]: F, [2019-12-07T00:44:47.279773 #4] FATAL -- : [f8400596-5b61-4569-ad22-b514afe4b32a] Errno::ENOENT (No such file or directory # rb_file_s_mtime - /app/storage/ST/yt/STyt8BUdPnbR1QxMYDN8YUiv)
The images were properly displayed when we fetched them via their URL in the assets pipeline.
So, what now ?
According to the logs, we guess this is a path issue. What are we missing ? At what point are we mistaken ?
We'll update the post with any required code snippet or test result, this is an educational project and nothing about it is private or sensitive.
Any insight or pointer appreciated :)
Workaround : use cloud storage instead of local disk in production
Since all the other images (background, logos, etc.) were displayed properly, the problem had to lie with our Active Storage use.
According to Heroku doc on Active Storage they use Ephemeral Disks for Active Storage and files are not persisted neither across dyno nor over time. So our guess was that our attachments were not stored on the dyno that served our application.
Connecting the production storage to a free-tier AWS bucket as suggested in Heroku doc worked for us and images are displayed properly.
With using webpack-s3-plugin npm package, I'm saving my laravel-mix compiled & versioned files into S3 (for cdn purposes).
Bare in mind, this was working until yesterday.
let webpackPlugins = [];
if (mix.inProduction() && process.env.UPLOAD_S3) {
webpackPlugins = [
new s3Plugin({
include: /.*\.(css|js)$/,
s3Options: {
accessKeyId: process.env.AWS_KEY,
secretAccessKey: process.env.AWS_SECRET,
region: process.env.AWS_REGION,
},
s3UploadOptions: {
Bucket: process.env.ASSETS_S3_BUCKET,
CacheControl: 'public, max-age=31536000'
},
basePath: 'assets/' + process.env.APP_ENV,
directory: 'public'
})
]
}
mix.scripts([ // I also tried '.combine'
'resources/js/vendor/vendor/jquery.slimscroll.js',
'resources/js/vendor/custom/theme-app.js',
], 'public/js/scripts.js')
// Other bundling stuff
.js([...].version()
mix.webpackConfig({
plugins: webpackPlugins
});
Now, S3's eTag doesn't match to mix-manifest.json hash. And, when I visit the page, it fetches 1 version behind, not the latest uploaded but exactly 1 previous version. However, when I check the 'updated date' on S3, it's correct. Nevertheless, it's exactly one version behind.
What I suspect is it is uploading to s3 before the bundling is completely done; however I am not sure. What am I missing here?
I used this guide if you want to know the laravel side in detail.
After diving around the S3 plugin source, I am fairly confident this is caused by the hook used to trigger the S3 upload. I don't know enough about webpack plugins to give a full description of this, but I have made an educated guess at what is causing the issue and my proposed fix seems to have sorted the issue.
The author of the plugin has accepted my pull request and the fix is currently awaiting release.
If you need a fix in the meantime, then you can do it like so (note, this is very dirty and should be treated as temporary):
Browse to your node_modules folder
Locate the folder named webpack-s3-plugin
Copy the file dist/s3_plugin.js
Paste somewhere in your project
Open the file and locate the line t.hooks.afterEmit.tapPromise
Replace with t.hooks.done.tapPromise
In your webpack.mix.js file, change the require('webpack-s3-plugin') to point to your javascript file
Just to reiterate, this is a temporary fix until the latest version of the plugin is released.
I added the demo files and ran the app just fine locally
But I ran into problems when i deployed to heroku, the content was not showing
I read through the documentation on the official site for nesta at
http://nestacms.com/docs/deployment/heroku
But they pretty much just make a comment rather than offering instruction
Make sure that you fill in config/config.yml properly (the most important thing is to ensure that caching is off, as we can’t write to Heroku’s file system).
Well I followed their documentation elsewhere
http://nestacms.com/docs/config
And then made changes to my config.yml file. Most relevant changes below
title: "Practice Nesta Site"
subtitle: "Nesta is pretty cool"
author:
name: Juan Gallardo
uri: nestademo1.herokuapp.com
email: jgallardo720#gmail.com
# cache
# Set it to true if you'd like Nesta to cache your pages in ./public.
# Useful if you're deploying Nesta with a proxy server such as Nginx,
# but not in the least bit helpful if your pages are dynamic, or you're
# deploying Nesta to Heroku.
#
cache: false
# content
# The root directory where nesta will look for your article files.
# Should contain "pages" and "attachments" subdirectories that contain
# your actual content and the (optional) menu.txt file that links to your
# main category pages.
#
content: content
# Overriding "cache" and "content" in production is recommended if you're
# deploying Nesta to your own server (but see the deployment documentation
# on the Nesta site). Setting google_analytics_code in production is
# recommended regardless of how you're deploying (if you have a GA account!).
#
# Don't forget to uncomment the "production:" line too...
production:
cache: false
content: /var/apps/nesta/shared/content
# google_analytics_code: "UA-???????-?"
read_more: See full page
Full file at this gist
https://gist.github.com/JGallardo/6195651
I ran heroku logs
jgallardo:demo-site juan.gallardo$ heroku logs
2013-08-09T17:22:21+00:00 heroku[slug-compiler]: Slug compilation started
2013-08-09T17:23:35.001505+00:00 heroku[api]: Scale to web=1 by jgallardo720#gmail.com
2013-08-09T17:23:35.026933+00:00 heroku[api]: Deploy 953af2e by jgallardo720#gmail.com
2013-08-09T17:23:35.046866+00:00 heroku[api]: Release v3 created by jgallardo720#gmail.com
2013-08-09T17:23:35.085708+00:00 heroku[api]: Deploy 953af2e by jgallardo720#gmail.com
2013-08-09T17:23:35+00:00 heroku[slug-compiler]: Slug compilation finished
2013-08-09T17:23:39.139164+00:00 heroku[web.1]: Starting process with commandbundle exec rackup config.ru -p 4751
2013-08-09T17:23:42.686255+00:00 app[web.1]: [2013-08-09 17:23:42] INFO WEBrick 1.3.1
2013-08-09T17:23:42.686255+00:00 app[web.1]: [2013-08-09 17:23:42] INFO ruby 2.0.0 (2013-06-27) [x86_64-linux]
2013-08-09T17:23:42.686477+00:00 app[web.1]: [2013-08-09 17:23:42] INFO WEBrick::HTTPServer#start: pid=2 port=4751
2013-08-09T17:23:43.030091+00:00 heroku[web.1]: State changed from starting to up
2013-08-09T17:36:17.229501+00:00 heroku[router]: at=info method=GET path=/ host=nestademo1.herokuapp.com fwd="98.173.1.66" dyno=web.1 connect=4ms service=51ms status=404 bytes=1570
2013-08-09T17:36:17.658553+00:00 heroku[router]: at=info method=GET path=/css/master.css host=nestademo1.herokuapp.com fwd="98.173.1.66" dyno=web.1 connect=4ms service=129ms status=200 bytes=5548
This line is the problem:
content: /var/apps/nesta/shared/content
Change it to this:
content: content
And make sure that your content is checked into the code repo. You've probably found this page already, right? http://nestacms.com/docs/deployment/heroku
I have what i imagine is a fairly common setup.
My rails 3 app is hosted on Heroku, and i use Paperclip to manage file uploading, of videos and images, with all files saved on Amazon S3. The model that the files are attached to is Entry, and the attachments themselves are called 'media'. So, I have paperclip set up like this:
class Entry < ActiveRecord::Base
has_attached_file :media, {:storage=>:s3,
:bucket=>"mybucketname",
:s3_credentials=> <credentials hash>}
This is all working fine. But, I now want to add download links to the files, so the user can download the videos for editing for example. I've done this as follows:
Download link on the page:
<p><%= link_to "Download", download_entry_path(entry) %></p>
This just calls a download action in EntriesController which looks like this:
def download
#entry = Entry.find(params[:id])
if #entry.media.file?
send_file #entry.media.to_file, :type => #entry.media_content_type,
:disposition => 'attachment',
:filename => #entry.media_file_name,
:x_sendfile => true
else
flash[:notice] = "Sorry, there was a problem downloading this file"
redirect_to report_path(#entry.report) and return
end
end
Since some of the downloads will be very large, i'd like to hive the download off to the server to avoid tying up a dyno. That's why i'm using the x_sendfile option. However, i don't think it's set up properly: in the heroku log i can see this:
2011-06-30T11:57:33+00:00 app[web.1]: X-Accel-Mapping header missing
2011-06-30T11:57:33+00:00 app[web.1]:
2011-06-30T11:57:33+00:00 app[web.1]: Started GET "/entries/7/download" for 77.89.149.137 at 2011-06-30 04:57:33 -0700
2011-06-30T11:57:33+00:00 app[web.1]: ### params = {"action"=>"download", "controller"=>"entries", "id"=>"7"}
2011-06-30T11:57:33+00:00 heroku[router]: GET <my-app>/entries/7/download dyno=web.1 queue=0 wait=0ms service=438ms status=200 bytes=94741
The "X-Accel-Mapping header missing" message suggests that something's not right, but i don't know what. Basically i don't know if heroku's nginx server takes on file downloading automatically, and if not then how to tell it to, and i can't find anything in heroku's documentation about it (i might be looking for the wrong thing).
Can anyone set me straight? Grateful for any advice - max
I'm not sure why you're sending files via the server. If they're stored on S3, why not just link right to them?
<%= link_to "Download", entry.media.url %>
That way the downloads bypass your Heroku server altogether.