I already knew that Google (as well as other search sites) doesn’t index .shtml pages, and it’s biting my butt here. Any one got the Apache directive to tell it “treat .html as .shtml in domain x only?”

Ahh, s’awright, I can figure it out. I know you can restrict server behavior on a domain by domain basis. This is really just one of those “where did I put my keys?” posts, which to my frustration I could NOT find a good example of (except for my lost hat of a few months ago).

6 thoughts on “gol darned google

  1. summink like that. I’ve already god ssi set up globally to perform in the conventional manner – i.e., foo.shtml

    I went ahead and did the deed: it’s

    AddHandler sever-parsed .html

    within the virtual server container for domain x, here, mike.whybark.com.

    Time will tell if google goes back to bein’ my buddy.

    I ‘member somthing about the XBitHack being deprecated these days but, um, as you can tell, I ain’t hit the books yet.

    Yes, shirt rec’d, thanks! I will provide photographic evidence, prolly here, shortly!

    I’m sorta saving up for another round of tinkering. I’m thinking about using Liyanage’s PHP distro instead of Apple’s ‘cuz his includes GD libs. Anyway. Tinkering is fun.

  2. Interesting that the XBitHack is being depreciated. The hack makes perfect sense — don’t want to have to waste all those cycles processing every single .html file on the site — and it’s implemented nicely, too.

    But I guess that you would run into issues on non-Unix OSes?

  3. Couldn’t find any evidence that my recollection of deprecation upon the hed of XBitHack is an accurate one.

    I bet I was recalling a security-policy specific overview of Apache implementation, since XBitHack is dependendent upon doc-level file perms.

    There may be a good reason to use XBitHack here, too:


    Since I’m defining foo.html as SSI-enabled for mike.whybark.com, if Google actually looks for Last-Modified header, or includes the presence of such in tests for indexing the site, I’ll still get no love.

    THus, XBitHack may be desirable.

    But I CAN see a potential direct security risk; it’s modeartely obtuse so i may not care, but I’d like to learn more about how concerned I should be.

    Can you see the securiy risk as well?

  4. It has something to do with executable files not really being executable, but beyond that, I have no idea. I’m still a long way from being a Unix Guru ™.

  5. Not quite – if I make these files (the ones that render in your browser) executable, and certain conditions are met (probably including enabling HTML in the comments, but not necessarily), it’s very easy to plant a server-side script within these pages, which could then be triggered remotely in several ways.

    All you’d need to do would be to include the script in your comments, given that the script is properly constructed.

    I’ll need to look into this more closely, because this seems too, too obvious. One supposes that the best way to avoid the problem is to set up the appropriate perms structure for your apache user. Perhaps this is the basis for the security policy I once read, or imagined.

Comments are now closed.