Dear Developers,
Downloading Files (pdf, doc, xls), when using https or ssl-connection, is not possible. This is due to the header. Cache is needed while using ssl and office-Files for example. It is quite an issue to get a working header - and i had to hack the module in order to get it working. I am not going to post my solution - solutions for this problems can be found within Drupal.org. In order to get the download working under all conditions, it would be necessary to offer header adaption. There are 3 possivle solutions:
a) fully automatic detection of connection - via js? Do not know, whether this will work - but it would be the optimum.
b) offer 2 different header settings for different implementations (without ssl, with ssl)
c) offer admin settings in order to adapt header variables
I think, it is a critical bug, because at the moment you are using ssl, this module will not work without hacking.
If you need some money to fix it properly, you can prepare an offer. If it is not to expensive, i would be willing to sponsor something - as i really need a working download.
regards
Christian
Comments
Comment #1
jpetso commentedI'm not an expert with SSL, but I do know that our site uses filefield successfully on a site that runs exclusively with HTTPS. Therefore I reject the claim that filefield doesn't work with SSL/HTTPS, because it does. It's totally possible though that one of your web server settings - which are most probably different from ours - makes the whole thing choke. (Example. I can imagine there are more of those.)
However, filefield only reuses (yeah, well, copies, ...but still.) the code from the core upload.module, and that one is supposed to do stuff right. filefield shouldn't do different stuff than all of the other download-enabling modules, so if you want this kind of functionality in filefield, please get it into core first. That means:
1. Search the issue queue for file.inc and upload.module for similar issues.
2. Research exactly which headers break which functionality, how that can be overcome, and what the implications are.
3. Write a patch, or get someone to write a patch for you.
4. Once your solution for core is tested and found feasible by the core devs, report back to the filefield issue queue and I'll get the changes in.
As for your proposed solutions, I think a) and c) are not feasible: a) because any code must also work correctly without JavaScript, and c) because it should really be possible to detect all necessary requirements automatically, and an admin interface would be an ugly workaround. (For ugly workarounds, we prefer private patches that stay out of any upstream release.) It is, however, possible to determine an HTTPS connection server side by querying one of the server variables (which one was it again...) so neither a) nor c) should be needed.
Please do notify this issue of the corresponding issue for Drupal core in case you open one. I'm closing this issue as "won't fix" because I think it's not in filefield's responsibility to fix this (assuming there is a general problem with download headers at all).
Also, you might try out filefield 2.x before trying further stuff. I'm not aware of any related changes since the 1.x version, but who knows :)