Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#2984 closed defect (bug) (worksforme)

404 response header on js.php file

Reported by: 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 9 years ago.

Download all attachments as: .zip

Change History (7)

9 years ago

#1 @ttscoff
9 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
9 years ago

Bump. Anyone have a comment on this?

#3 @xurizaemon
9 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
9 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
9 years ago

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

Unable to reproduce this on my blog.

#6 @anatman
7 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.