Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
a guy postet a usefuly tip here how to use this module for apache with only some minor changes.
Comments
Comment #1
marcoka CreditAttribution: marcoka commentedmy thoughts on that is that its a better idea to put that stuff into an own apache xsendfile module. any other thoughts?
Comment #2
perusio CreditAttribution: perusio commentedHello,
Thanks for bringing this issue to my attention.
If you want to help, great. Just say the word and I'll give you commit access.
Comment #3
marcoka CreditAttribution: marcoka commentedok good. i will take a look at the code and think about the apache implementation because i need that for a project.
i will report if i have a good solution/patch
Comment #4
marcoka CreditAttribution: marcoka commentedif we merge, we should rename the module to xsendfile because thats the name of both
http://wiki.nginx.org/XSendfile
https://tn123.org/mod_xsendfile/
what do you think?
Comment #5
marcoka CreditAttribution: marcoka commentedAnother important question for me.
Currently i am working on a module i call "image_styles_protection" its purpos is to rotect certain image styles so one can set download permissions on image styles.
I do that by adding htaccess files to the folders and rewritig the url so i can go through the hook_file_download.
I have to implement some check inside the nginx_accel_redirect_file_transfer() because when using "image_styles_protection" a check for:
The file_exists($uri); in that case needs still "public://"
Would it be ok if i implement that small check for kind of an "addon module". If not i can understand but then i would then need to fork.
The intention behind "image_styles_protection" is only protecting very large presets while leaving thumbnails and other small presets unprotected for good performance overall. For example if someone builds a stockphoto site, or some site that has preset X and Y for free but to download Z you need to be a member.
Comment #6
perusio CreditAttribution: perusio commentedThat's an issue because that namespace in d.o projects is already taken.
EDIT: I jumped the gun the project is called x-send. Yes I'm on board with it.
Comment #7
perusio CreditAttribution: perusio commentedCould you elaborate further? From what I understand that can and should be done at the server level. Seems to be too specific.
We could have a generic image styles protection mechanism but I'm afraid it would make the code more complex. What we can do is post an example on how do that at server level in the project page/docs.
Comment #8
marcoka CreditAttribution: marcoka commentedi am working on a module that does the protection (image_styles_protection). the only thing it needs to work with the xsendfile project(Nginx Accel Redirect) is some small check inside the nginx_accel_redirect_file_transfer().
i think i will make that small changes and show it to you when i finish it.
Comment #9
marcoka CreditAttribution: marcoka commentedi figured it out without adding checks for my module inside the current code.
i created the project and added you giving you full access.
http://drupal.org/project/xsendfile
i will now start
- rewriting the admin ui adding the apache settings with the usage of form #state to show different config infos.
- renaming to the new project/namespace
- adding switch for apache/nginx header.
i will then put it up to, so you can take a look.
http://drupal.org/project/xsendfile
Comment #10
marcoka CreditAttribution: marcoka commentedI pushed the first version. So you could take a look.
Changes:
- rewriting the admin ui adding the apache settings with the usage of form #state to show different config infos.
- renaming to the new project/namespace
- adding switch for apache/nginx header
- fixed paths in on the hook_help
Comment #11
perusio CreditAttribution: perusio commentedOk. Thanks. I'll have a look at it next monday. I'm unable to do it before due to a very busy schedule :( This task requires quality time.
Comment #12
marcoka CreditAttribution: marcoka commentedno rush on this. i am currently using the current version on a project, kind of an image library with tons of high resolution images. so i am kind of beta testing it for apache.
Comment #13
damien_vancouver CreditAttribution: damien_vancouver commentedI just wanted to post here too so @perusio sees it. I need X-Sendfile for some production sites with large private audio files, and I use Apache, is where I came from :) We've been discussing the new merged xsendfile module a bit here: #1515466: Documentation improvements and also here #1407532: Compare with xsend project, and I'm going to contribute some documentation and hopefully help move the merging/releasing/testing along while I do.
I just fixed the xsendfile project's 7.x-1.x branch in git, which should make the version control tab work properly in short order.
Next steps should probably be to:
- verify we're all on board still :)
- get perusio added as a maintainer on the XSendFile project so he has access to version control and editing the module description
- Copy over the excellent module description information from this project page onto the xsendfile page, and beef up the documentation there to be complete for Apache too (I can handle the edits and cleanup, if perusio could maybe copy over the contents of the module description).
- Further documentation improvements and testing over at xsendfile. I have in mind both proper apache documentation and also better install/troubleshooting testing. For bonus marks we could maybe even get a simpletest going that detects any problems (which usually result in 0 byte files being served)
- Making a stable/recommended release (or beta2 at least)
- redirecting people who show up to this module, and getting a link put on the old D5/D6 "xsend" module to the new xsendfile merged spot as well.
@perusio, so how is your time looking these days? I don't think we'd need much of it but certainly it would be good to have you test the xsendfile project vs. some real nginx setups. While the code changes in #10 look minor in scope we won't know for certain they haven't broken anything without testing.
Comment #14
perusio CreditAttribution: perusio commented@damien_vancouver
I'm getting up on cruise speed. I'll address this issue tomorrow. Yes I have been MIA regarding this project. In fact the merge makes all sense and tests are something on my plans at least for the Nginx part. The merge will be for the 7.x version.
Add me as a maintainer to the xsendfile project. Let's get this ball rolling again. Some of the documentation for Nginx can be used for XSendfile also. The principle is the same. Is just the configuration directives that change and the header name
X-Sendfile
vs.X-Accel-Redirect
.Comment #15
marcoka CreditAttribution: marcoka commentedyou have been added as full maintainer
Comment #16
damien_vancouver CreditAttribution: damien_vancouver commented@perusio, awesome!
We're all busy so let's not kill ourselves trying to make this happen overnight.. but I think once we're all in the new project then it shouldn't take us too long to get to a release.
Things I'd like to see before a 1.0 are mainly apache documentation related:
- Improved apache admin UI, that correctly figures out what version of xsendfile you have installed and gives you the correct configuration directive (it's either "XSendFileAllowAbove On" or "XSendFilePath /path/to/private/files/dir" depending on what version of the Apache module you have installed on your system. The wrong directive breaks Apache badly... in hindsight it should have been depreacted gracefully instead of outright removed in the apache module source)
- improve Apache admin UI documentation - right now it directs you to make changes to .htaccess. We should provide better instructions advising you to make the changes in the webserver configuration instead (if possible). Otherwise, .htaccess updates with a new drupal core upgrade will overwrite your XSendfile directives, leading to a broken configuration that serves up 0 byte files
- improve setup / troubleshooting documentation (I'll do that too but might need help on the nginx parts!) I'm thinking a debug checkbox might help here too, so you can at least see from a watchdog log entry that "it's really working".
That's really all I can think of. Feature-wise I think the module is complete other than those minor UI improvements and the docs.
Comment #16.0
damien_vancouver CreditAttribution: damien_vancouver commented.