a guy postet a usefuly tip here how to use this module for apache with only some minor changes.

#1080824: Any plan to port this to drupal 7?

Comments

marcoka’s picture

Assigned: Unassigned » marcoka

my thoughts on that is that its a better idea to put that stuff into an own apache xsendfile module. any other thoughts?

perusio’s picture

Hello,

Thanks for bringing this issue to my attention.

  1. I don't think it makes sense to create another module if what needs to be changed to have it function is a line.
  2. I'm starting a 7.x-2.x-dev branch I'll add some code for server detection. After all with Apache there's an API that can be used to gather information about the server.
  3. Most of the stuff can be used. The only thing that needs to be different is the configuration suggestions on the settings page.

If you want to help, great. Just say the word and I'll give you commit access.

marcoka’s picture

ok 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

marcoka’s picture

if 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?

marcoka’s picture

Another 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.

RewriteEngine on
RewriteBase /system/files/styles/a4000
RewriteRule ^(.*)$ $1 [L,R=301]

I have to implement some check inside the nginx_accel_redirect_file_transfer() because when using "image_styles_protection" a check for:

$foo3 = file_exists('public://styles/a4000/public/TEXTUREN/foo/marco/PRODUCT1_500x375.jpg');   //WORKS
$foo4 = file_exists('private://styles/a4000/public/TEXTUREN/foo/marco/PRODUCT1_500x375.jpg');

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.

perusio’s picture

That'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.

perusio’s picture

Could 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.

marcoka’s picture

i 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.

marcoka’s picture

i 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

marcoka’s picture

Status: Active » Needs review

I 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

perusio’s picture

Ok. 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.

marcoka’s picture

no 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.

damien_vancouver’s picture

I 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.

perusio’s picture

@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.

marcoka’s picture

you have been added as full maintainer

damien_vancouver’s picture

@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.

damien_vancouver’s picture

Issue summary: View changes

.