#21993 [NEW]: Frameset/PHP conflict
| From: | black_dragon5 at juno dot com | Date: | Sat, 01 Feb 2003 08:00:50 +0000 |
| Subject: | #21993 [NEW]: Frameset/PHP conflict | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-31829@lists.php.net to get a copy of this message | ||
From: black_dragon5@juno.com
Operating system: Windows NT 5.1 (IIS 5.1)
PHP version: 4.3.0
PHP Bug Type: Unknown/Other Function
Bug description: Frameset/PHP conflict
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 bug report at http://bugs.php.net/?id=21993&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21993&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21993&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21993&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21993&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21993&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=21993&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21993&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=21993&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=21993&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21993&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21993&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21993&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21993&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=21993&r=gnused