like you, i initially thought this was a matter due to caching. i then changed my script to serve a file that has NEVER PREVIOUSLY been opened in the browser (to see if in fact, the client browser would request in response to the redirect HTTP headers). unfortunately, the file referenced in the HTTP redirect was NOT opened in the browser - so this tells me the problem has nothing to do with caching.

ive distilled the program down to its 'bare-bones' version to show the relevant code. this is not my actual program, but only serves to demonstrate the problem.

use HTTP::Daemon;
use LWP::UserAgent;

my $ua = LWP::UserAgent->new();
my $d  = HTTP::Daemon->new( 
         LocalHost => "localhost",  # remove this to listen from other
+ machines 
                                    # (i.e. open-relay... be careful o
+f spammers!)
     LocalPort => 8888          #always best to run 'netstat -ano | fi
+nd "8888"' prior to running this command (to find an unused port)
) || die;                           #after this program is launched ru
+n again 'netstat -ano | find "8888"' to confirm this port is now bein
+g bound to this program
                                    #then to actually use this with a 
+browser must go to browsers proxy setting (a global windows setting):
+ set server=127.0.0.1 port=8888

#main 'accept-getrequest-process' loop is the next two lines
while (my $c = $d->accept) {
   while (my $request = $c->get_request) {

      #we wish to send the web client browser a redirect to a local fi
+le on his same machine
      #as a test of the nifty 'send_redirect' function
      #since this particular file has never before been opened in the 
+web browser
      #if it does NOT open/display in the client web browser
      #the fault for this can NOT be attributed to caching issues
      #unfortunately, when this proxy program is ran, and the computer
+ environment told to use this proxy
      #this page never displays in the client web browser window (i am
+ unsure as to why it does not display.
      #ive also tried various "300" codes, 301, 302,303, 307 with no c
+hange in the result.)

      #because 'Wireshark' cant capture traffic thats on the localhost
+ (eg: not being sent out of the network card)
      #i have no way to 'view' the actual data being sent between the 
+client program and the proxy program (on Windows)

      $c->send_redirect("file:///C:/http_proxy_server/FileThatsNeverBe
+foreBeenOpenedInTheBrowser_eg-NotCached.html", 303);

   }
   $c->close;
   undef($c);
}
[download]

note because the client (browser app) and server (perl proxy server program) are both running on the same machine - this is particularly hard to troubleshoot as 'wireshark' does not capture any TCP packets that are not actually sent out of the network card. does anyone know how to monitor TCP/IP traffic sent/received to the 'localhost' only?

According to the Browser Security Handbook, it's not possible for websites to redirect to file: URLs. The rationale is explained a bit in the section "URL scheme access rules" just before the linked section.

Since you've already got a working HTTP server, why not serve the file over that, via a special URL?

last evening, i was finally able to find a program that allowed me to monitor the TCP flow on my localhost (between my web browser and this Perl proxy program). Wireshark can not do this, but an app called RawCap can. I saved the *.pcap log file, opened it in Wireshark and applied the proper filter 'tcp.port eq 8888' and it revealed the stream. I saw a properly formatted HTTP redirect was in fact sent - so that then lead me down the same path you came up with. i started to search to see what most browsers would do in this situation. i found the exact same document that you referenced, and read that indeed no normally available browsers will make a request to a local file in response to a redirect. so yes, another approach will need to be taken. Either my Perl proxy program will need to directly send the file using HTTP, or i can install a local web browser and simply redirect to my local web server's html folder.

thanks for your help - as this was driving me batty. now i know the direction i need to take!