Op donderdag 8 juni 2006 13:58, schreef Morbus Iff:
Today I ran into another server that did not allow .htaccess. If it finds one, it dies with a 500 (I beleive this is non standard, but it might be used in more places, I saw it twice). A person asked for my help because
That is not correct. If the server did not allow an .htaccess file, it would *ignore* them. In your case, the server *is* allowing an .htaccess file of some kind, only the directives that Drupal ships with are unallowed for the user, and thus it gives a 500. If you check your Apache error log, you'll get the exact reasoning.
Yes. I should have been more precice. Not hte file itself, but something inside it broke the server. The server, however, allows *nothing*. So virtuallly similar ot "when a .htaccess exists a 500 occurs".
However, you may be running up against:
Indeed. I will follow up there.
We should not make .htaccess files from with Drupal, not on upgrades and not after installation. Or at least not in this particular situation. It locks people out, without a hint whats happening
Again, not entirely accurate. The only .htaccess we create in Drupal is in the user's configured "files" directory. The only time the 500 error would occur is if someone *directly* accessed a URL under the files/ directory. If you're seeing otherwise, then you've got a really weird server, and we can't cater to it without negatively impacting commons.
Rather accurate. logos and images are served from there. They caused a 500 when displaying inline. (resulting in borken images).
recently. We now rely on this file, inside the files dir, for security, meaning if you remove that file, you might be less secured. We must at least document this.
Removing the file is irrelevant - you remove it and Drupal will recreate it during the next file upload. You'd have to zero-byte it instead.
Yes. echo '' > files/.htaccess did the trick. Still teh fact remains that we (Drupal) rely on common set-ups and with that, apparently break some rather exotic set-ups. I m not sure if this is good or bad, or if we should care. I am not trying to fix anything, nor trying to tell we should change anything. I only wanted to point this out. Point out that our model is not yet full-proof. Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc Drupal upgrade repareert kritiek beveiligingslek: http://help.sympal.nl/drupal_upgrade_repareert_kritiek_beveiligingslek