Fixed a major problem here that has been plaguing me for some time. All content is stored in a mysql database, and these pages are all assembled on the fly when you request them. So the particular URLs (like /jim/weblg/) don't really exist in the file system on the server. Instead, every request is sent to a central php script that parses the REQUEST_URI, looks up the path in the database and then grabs all the posts associated with that page and spits them out. I had been doing the redirection with an errordocument line in my .htaccess file pointing to the central php script (so it was like every request was 404ing, but then the 404 page was the central script that would then built each page.) In any case, the problem was that the server was sending a 404 code back to the browser in the head immediately followed by a 200 OK code. Even though that is not correct, most browsers had no problem with this. But a few did. Like some versions of IE on the MacOS and at least one of the Opera betas on the MacOS. After much struggle to find a way around this I just figured out that my host has mod_rewrite enabled, and that I can access this through my .htaccess file. So now the redirection is done with a rewrite rule instead of an error document and I believe this has solved the problem. Rex Swaine's handy HTTP viewer helped me out a lot in fixing this. |
return to: jimslog |
"...ystemnews/pageforward/10719/?/ Content-Length: 0 Connection: close Content-Type: text/html; charset=ISO-8859-1 ..." |
"...ystemnews/pageback/11857/?/ Content-Length: 0 Connection: close Content-Type: text/html; charset=ISO-8859-1 ..." |
"...ystemnews/pageforward/10172/?/ Content-Length: 0 Connection: close Content-Type: text/html; charset=ISO-8859-1 ..." |