ID:               21993
 Updated by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
-Status:           Open
+Status:           Feedback
 Bug Type:         Unknown/Other Function
 Operating System: Windows NT 5.1 (IIS 5.1)
 PHP Version:      4.3.0
 New Comment:

Does it work on another server ? 
Apache, or does it work with isapi ? 
 
What is the content of the files ? 


Previous Comments:
------------------------------------------------------------------------

[2003-02-01 02:00:50] [EMAIL PROTECTED]

This is an error that was not present in version 4.2.3.  Somehow,
framesets aren't working very well with the new version, 4.3.0.  Here
is the frameset:
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>
<frameset rows="56,*" frameborder="NO" border="0" framespacing="0">
  <frame src="top.php" name="topFrame" scrolling="NO" noresize >
  <frame src="main.php" name="mainFrame">
</frameset>
<noframes><body>
</body></noframes>
</html>

the file 'top.php' actually does not have any PHP code in it yet, but
retained the '.php' extension for future expansion (this was the bare
layout for a new website).  Before, all of these files were
XHTML-compliant, with a PHP echo generating the <?xml
version="1.0"...?>

The interesting thing about this is that when I first load the page, it
will tell me "The page cannot be displayed".  If I refresh the page,
the frameset is gone, and it gives me "The directory name is invalid.".
 However, if I load one of the pages (either top.php or main.php) by
bypassing the frameset and then go back using the frameset, that page
will load.  Additionally, sometimes when I hit the back button it will
load one of the pages, but if I try to go forward or back to the page,
I get a 500 internal server error.  

I am using IIS 5.1 included with NT 5.1 (Windows XP Professional) with
the CGI version of 4.3.0.  Pages were generated with Dreamweaver and
edited with Notepad.  Some additional thoughts: This could be a server
configuration problem, but I think it is highly unlikely due to 4.2.3
working with the same type of page (two earlier prototypes pioneered
this method; both worked fine [but are still unfinished]).  Note: I
believe this is different from the other bug reports due to the fact
that there is no PHP code in these pages whatsoever, and I have checked
the php.ini file.  It works fine when given a .htm or .html extension,
but does not when it uses .php.  If I am incorrect in stating that this
is a unique bug, please feel free to correct me. 

Oh yes.  Happy Chinese New Year! =P


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=21993&edit=1

Reply via email to