well, what i'm discovering is two fold... one is easily taken care of (and was when the site was offline the other night) and has to do with file permissions.... if a function calls another that requests a file and if that file has a permission that isn't publicly executable it would trigger the 403... the problem wasn't with the file permissions i set, as it turns out, it was with an automated 'audit' function i'd installed that reset families of files to permissions after i'd altered them.... so i would change the permission and not look back, and when encountering the 403 again would think "well, that wasn't it" just to return and find it was....... so i spent a good several hours trying to figure out what was causing it... thought i had beaten it.
but this is more likely, at this point: i purposely slowed the page down. i did so because it was rendering before qualifications could be passed, and if the 'below the fold' sessions verification hadn't completed before the screen was populated, it will give a 403. the page used to render in less than a second- around 7.7ms to be precise, recorded out of Dayton and out of L.A.... adding some scripts back to it brought it into the 1.5 range and also diminished the 403's quite a bit... i fear the same is happening now, even though the server is still offering up in the 2 second range... any slower than that for a desktop with physical connection is bad, especially for wireless devices...
i'll find it, though... and i appreciate the heads up. i'll go sifting through the posting calls and see if any permissions have reset or if i can move the sessions verification higher in the call.
