Make WordPress Core

Opened 16 years ago

Closed 15 years ago

Last modified 14 years ago

#2984 closed defect (bug) (worksforme)

404 response header on js.php file

Reported by: ttscoff's profile ttscoff Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.0.4
Component: General Keywords: 404 bug
Focuses: Cc:


I've been working (unoffically) on the Extended Live Archives Plugin. There was a problem that quite a few users were experiencing where no archives were showing up and no errors or AJAX transactions were reported. I found that the PHP as CGI file was returning valid javascript, which was properly embedded in the generated source for the page. But when I accessed the php file directly, it showed up fine, but with a response header of 404 Not Found. This caused it to be ignored by all browsers except Safari (Mac). I modified the functions.php file temporarily to force a 200 on these pages, but I'm fully aware that this is a poor solution. What I'd really like to know is what is causing these 404 headers on this particular script?

I'm running Apache/1.3.37 with mySQL 4.0.25. Wordpress 2.0.4

The offending file can be seen here, and if you check the response headers, you'll see the 404 error.

Thanks for any assistance.


Attachments (1)

functions.php (71.1 KB) - added by ttscoff 16 years ago.

Download all attachments as: .zip

Change History (7)

16 years ago

#1 @ttscoff
16 years ago

My apologies, with my modified functions.php you won't get the 404 error on the linked file. Let me know if you'd like me to revert it so you can see the error.


#2 @ttscoff
16 years ago

Bump. Anyone have a comment on this?

#3 @xurizaemon
16 years ago

Bump. This code shouldn't generate a 404 header in an external file that wants to access WP things, but rather only if WordPress can't find the content.

My js.php file parses fine, but WP(2.0) returns a 404 header as a special bonus. So (as a crude workaround) I just rewrote the headers I didn't like, once wp-blog-header.php had done its filth.

Alternatively, some other non-404ing method should be available to use WP's functions without it owning the headers. (Perhaps I missed that in the docs.)


define('WP_USE_THEMES', false) ;
header("HTTP/1.1 200 OK");
header("Status: 200 All rosy") ;


404 should only get set IF wordpress really is dealing with the request, IMO.

#4 @xurizaemon
16 years ago

  define('WP_USE_THEMES', false) ;
  require('../../../wp-blog-header.php'); // i'm in wp-content/themes/js.php
  header("HTTP/1.1 200 OK");  // else we get 404
  header("Status: 200 All rosy") ; // what should this really say?

#5 @Nazgul
15 years ago

  • Resolution set to worksforme
  • Status changed from new to closed

Unable to reproduce this on my blog.

#6 @anatman
14 years ago

After much headbanging, found this out:

Turns out that PHP4 running under Fast CGI (maybe under CGI too) has a known bug, which causes a problem with URL rewriting. Wordpress URL rewrites may seem buggy in this environment, and/or the response headers will contain an unexpected 404 OK (when it should be 200 OK or 404 NOT FOUND).

The solution is to run PHP as a module, or to upgrade PHP to version 5.

Note: See TracTickets for help on using tickets.