.info domains access denied

"sh" is a top level domain, too ("St. Helena") ;-). But I don't think this domain is used as much as ".info".

this opens up for people/robots to index the .info -files under modules directory?

I'm not entirely sure how this is possible. This is a FilesMatch, not a DomainMatch (which doesn't exactly exist).

If this is correct, I should be able to reproduce the bug by adding net or com to this list for a site with either of those as a TLD, right?

I tried this with net and see no effect on the site. In contrast, removing inc from the list lets me view .inc files.

moonray: could you try http://www.yourdomain.com/ (ending slash) and http://www.yourdomain.com (no ending slash) and tell me what, if anything, changes? This sounds like an Apache FAQ, really. http://httpd.apache.org/docs/1.3/misc/FAQ-E.html#set-servername

No, that'd have nothing to do with it. That's a directory. FilesMatch only works on Files. It doesn't look at directory names at all.

I was not able to access front page after 5.1 upgrade (but domain.info/node was working fine). And the trick with modifying .htaccess actually helped. Upgrade is running as domain.info and 4.5 was at sub.domain.info (running without a problem for couple of years and misc. apache/php updates).

YES! I have - 2 days I cant fix it. I tried Your staff - no result. On The .info domain - Error 500: Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request.

Yes, I DID IT!!!
For all with .info domains - this is correct .htaccess file.
Really - I miss |info| and all get works. See attach

This can happen when the website is located in a folder named "/my/webroot/folder/domain.info". In that case, the FileMatch directive will try to match the folder itself when "http://domain.info/" is called. We should switch to LocationMatch and the issue will go away.

#349470: Base URL is forbidden on .info domains. was a duplicate.

Damien: you'll have to provide more proof then that, unfortunately.

* Where is the Apache documentation that says FilesMatch works on full paths?
* Where is the Apache documentation that says FilesMatch works on directories?
* Where is the Apache documentation that says .htaccess files care about the location of the parent folder?
* How do you propose to allow LocationMatch to let dynamic Drupal-created URLs through, but not the actual files we're trying to protect?

I set up a .htaccess in a example.info directory, with:

<FilesMatch "\.info$">
  Order allow,deny
</FilesMatch>

Results:
http://dev.drupalfr.org/example.info/ ===> works
http://dev.drupalfr.org/example.info/test.html ===> works
http://dev.drupalfr.org/example.info/test.inf ===> 403
http://dev.drupalfr.org/example.info ===> 403

So FilesMatch *does* match directories in some weird cases. Granted, this is an Apache bug, but what can we do about it?

Not perpetuate it by depending it ;)

I'll do some more testing later.

Has this been resolved?

Same question as #19

I can reproduce the error in #16. I can't reproduce the error with a .info domain name. Nevertheless, if a user chooses to install Drupal at example.com/foo.info/, then they should not get access denied errors when visiting example.com/foo.info.

While it may be an Apache bug, there should at least be a comment added to the .htaccess file to help those who experience this. I just spent a few hours tracking this one down. The site was also stored in a folder ending in ".info", and I was able to fix the issue by moving the site to a folder ending in "_info".

Just to clarify, my DocumentRoot was /var/www/e/x/a/example1/sites/example2.info/ and the affected URL was http://www.example2.info/. This only affected the home page, all other pages (clean URLs) were fine. If I tried to go to a URL like http://www.example2.info/q=admin, then the error persisted.

Note this was with GoDaddy hosting.

Tagging

Fixing tags per http://drupal.org/node/1517250

Here's a crazy idea, but changing the Drupal info file extension to ".ini" would solve this, since this is the file format used to read in these files parse_ini_file().

Alternatively, ".conf" or ".cfg" might also work and make sense: get_cfg_var().

What do other projects like symphony use for config files? Converting to yaml would be another idea to consider, even if its justification (just to solve this issue) is a bit far fetched. Not sure if someone has been thinking about this kind of thing yet or not for D8.

UPDATE: I was unsure about my justification above, and searched the codebase... and it turns out I was wrong :P the *.info file *is* custom to Drupal. See drupal_parse_info_format().

@jwilson3: #1793074: Convert .info files to YAML ;)

@jwilson3, You were mostly right the first time: the drupal_parse_info_format function is actually a PHP implementation of parse_ini_file. The original parser was added when we added .info files to themes: #132018: Add .info files to themes (and improve/clean up the theme system)

Well isnt that just awesome. Assuming that patch lands, this is fixed for D8. No solution for D7, other than the workaround to move the installation folder.

Please, look at my work.

Seems fixed for 8.0.x, since we use .yml now not .info, though this does seem like it could interfere with file uploads.