[development] no .htaccess perms 500 kills drupal.
ber at webschuur.com
Fri Jun 9 13:30:45 UTC 2006
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.
PGP ber at webschuur.com
Drupal upgrade repareert kritiek beveiligingslek:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060609/4895f033/attachment.pgp
More information about the development