469,288 Members | 2,353 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,288 developers. It's quick & easy.

Php function run twice, why?

The following script generates two files copies. (I expect that a new
file is created in my $wrk_dir)

The same script executed without Apache works properly and generates
single file copy.

With $URL_CSS_ defined works properly. (row 13)

Deleting row 15 works properly.

Apache seems to execute twice the script, second in background. I
don't
understand why.

<?
$id = uniqid('bug');
$wrk_dir = ''; // Working Directory
$src_file = 'grab.jpg'; // Source File
$dst_file = 'tmpgrab_'.$id.'.jpg'; // New File

echo 'Source File ='.$src_file.'<br />'; // Print Source File
Name
echo 'Destination File ='.$dst_file.'<br />'; // Print Destination
File Name

if (!copy($wrk_dir.$src_file, $wrk_dir.$dst_file)) {
echo 'Failed to copy.<br />';
}
//$URL_CSS_='string';
?>
<link rel="stylesheet" href="<?=$URL_CSS_?>" type="text/css" />
Tested with:
Php 5.0.1 - 4.3.9 - 4.3.4
On Linux System, kernel 2.4, 2.6

In Windows seems to work properly. (not tested personally)
Any ideas?
Jul 17 '05 #1
12 8223
ic**@email.it wrote:
The following script generates two files copies. (I expect that a new
file is created in my $wrk_dir)

The same script executed without Apache works properly and generates
single file copy.

With $URL_CSS_ defined works properly. (row 13)

Deleting row 15 works properly.

Apache seems to execute twice the script, second in background. I
don't understand why.

<?
$id = uniqid('bug');
$wrk_dir = ''; // Working Directory
$src_file = 'grab.jpg'; // Source File
$dst_file = 'tmpgrab_'.$id.'.jpg'; // New File

echo 'Source File ='.$src_file.'<br />'; // Print Source File
Name
echo 'Destination File ='.$dst_file.'<br />'; // Print Destination
File Name

if (!copy($wrk_dir.$src_file, $wrk_dir.$dst_file)) {
echo 'Failed to copy.<br />';
}
//$URL_CSS_='string';
?>
<link rel="stylesheet" href="<?=$URL_CSS_?>" type="text/css" />
What's the HTML output of this line?
I guess it is

<link rel="stylesheet" href="" type="text/css" />
I think perhaps the browser requests the "text/css" file "" (without the
quotes) and makes Apache (correctly?) run the script twice.

If you test $URL_CSS_ before printing the link, you should be ok:

<?php
unset($URL_CSS_);
if (rand(0, 1) == 1) $URL_CSS_ = 'string';
?>

<?php if (isset($URL_CSS_)) { ?>
<link rel="stylesheet" href="<?php echo $URL_CSS_; ?>" type="text/css" />
<?php } ?>
Tested with:


not tested! :-)

--
Mail sent to my "From:" address is publicly readable at http://www.dodgeit.com/
== ** ## !! !! ## ** ==
TEXT-ONLY mail to the complete "Reply-To:" address ("My Name" <my@address>) may
bypass the spam filter. I will answer all pertinent mails from a valid address.
Jul 17 '05 #2
Pedro Graca wrote:
ic**@email.it wrote:
The following script generates two files copies. (I expect that a new
file is created in my $wrk_dir)

The same script executed without Apache works properly and generates
single file copy.

With $URL_CSS_ defined works properly. (row 13)

Deleting row 15 works properly.

Apache seems to execute twice the script, second in background. I
don't understand why.

<?
$id = uniqid('bug');
$wrk_dir = ''; // Working Directory
$src_file = 'grab.jpg'; // Source File
$dst_file = 'tmpgrab_'.$id.'.jpg'; // New File

echo 'Source File ='.$src_file.'<br />'; // Print Source File
Name
echo 'Destination File ='.$dst_file.'<br />'; // Print Destination
File Name

if (!copy($wrk_dir.$src_file, $wrk_dir.$dst_file)) {
echo 'Failed to copy.<br />';
}
//$URL_CSS_='string';
?>
<link rel="stylesheet" href="<?=$URL_CSS_?>" type="text/css" />


What's the HTML output of this line?
I guess it is

<link rel="stylesheet" href="" type="text/css" />
I think perhaps the browser requests the "text/css" file "" (without the
quotes) and makes Apache (correctly?) run the script twice.

If you test $URL_CSS_ before printing the link, you should be ok:

<?php
unset($URL_CSS_);
if (rand(0, 1) == 1) $URL_CSS_ = 'string';
?>

<?php if (isset($URL_CSS_)) { ?>
<link rel="stylesheet" href="<?php echo $URL_CSS_; ?>" type="text/css"
/> <?php } ?>
Tested with:


not tested! :-)


thanks! but I'd like to understand if it's a bug (php module? apache? or
other...)

other example: :)
Run following two pages in your system and see apache log file.

---------------
filename

content
---------------
----------------------------------------
page.htm

<img src="" alt="No source specified" />
----------------------------------------
----------------------------------------
page.php

<img src="" alt="No source specified" />
----------------------------------------
htm extension: page run properly, once.
log:
192.168.1.2 - - [17/Nov/2004:00:44:17 +0100] "GET /bug/page.htm HTTP/1.1"
200 41
php extension: page run twice.
log:
192.168.1.2 - - [17/Nov/2004:00:44:27 +0100] "GET /bug/page.php HTTP/1.1"
200 41
192.168.1.2 - - [17/Nov/2004:00:44:27 +0100] "GET /bug/page.php HTTP/1.1"
200 41

why? :)

Jul 17 '05 #3
i-c-u-i wrote:
Run following two pages in your system and see apache log file.

----------------------------------------
page.htm

<img src="" alt="No source specified" />
----------------------------------------
----------------------------------------
page.php

<img src="" alt="No source specified" />
----------------------------------------
htm extension: page run properly, once.
log:
192.168.1.2 - - [17/Nov/2004:00:44:17 +0100] "GET /bug/page.htm HTTP/1.1"
200 41
php extension: page run twice.
log:
192.168.1.2 - - [17/Nov/2004:00:44:27 +0100] "GET /bug/page.php HTTP/1.1"
200 41
192.168.1.2 - - [17/Nov/2004:00:44:27 +0100] "GET /bug/page.php HTTP/1.1"
200 41

why? :)


Same thing happens here with Firefox, but not with Elinks.

I believe the reason lies in how the browser builds the request.
For HTML pages it uses caching, for PHP pages it doesn't.

Unfortunately "Live HTTP headers" stopped working with Firefox and it
would be more trouble than I care to take right now to compare all the
request headers of the different browsers for the two pages :)
--
Mail sent to my "From:" address is publicly readable at http://www.dodgeit.com/
== ** ## !! !! ## ** ==
TEXT-ONLY mail to the complete "Reply-To:" address ("My Name" <my@address>) may
bypass the spam filter. I will answer all pertinent mails from a valid address.
Jul 17 '05 #4
Pedro Graca wrote:
Same thing happens here with Firefox, but not with Elinks.


D'oh! Of course it doesn't happen with Elinks!
Elinks will *never* request an image.

--
Mail sent to my "From:" address is publicly readable at http://www.dodgeit.com/
== ** ## !! !! ## ** ==
TEXT-ONLY mail to the complete "Reply-To:" address ("My Name" <my@address>) may
bypass the spam filter. I will answer all pertinent mails from a valid address.
Jul 17 '05 #5
Pedro Graca wrote:
Pedro Graca wrote:
Same thing happens here with Firefox, but not with Elinks.


D'oh! Of course it doesn't happen with Elinks!
Elinks will *never* request an image.


True!
Two GET in log file.... sobh! it was easy.... :)

Now tested with Opera and iexplorer:

all ok

Problem only with firefox.
thanks for your help! ;)


Jul 17 '05 #6


<link rel="stylesheet" href="<?=$URL_CSS_?>" type="text/css" />


What's the HTML output of this line?
I guess it is

<link rel="stylesheet" href="" type="text/css" />

I think perhaps the browser requests the "text/css" file "" (without the
quotes) and makes Apache (correctly?) run the script twice.


I agree that this is probably the reason. A link to "" is generally a link
to the same page, so Firefox is arguably correctly trying to download the
same page as a CSS file.
Martin
k
Jul 17 '05 #7
.oO(i-c-u-i)
thanks! but I'd like to understand if it's a bug (php module? apache? or
other...)
Neither nor.
----------------------------------------
page.htm

<img src="" alt="No source specified" />
----------------------------------------

----------------------------------------
page.php

<img src="" alt="No source specified" />
----------------------------------------
Results in FF 1.0:

.... [17/Nov/2004:16:54:52 +0100] "GET /page.html HTTP/1.1" 200 109
.... [17/Nov/2004:16:55:05 +0100] "GET /page.php HTTP/1.1" 200 123
.... [17/Nov/2004:16:55:06 +0100] "GET /page.php HTTP/1.1" 200 123

Results in IE 5:

.... [17/Nov/2004:16:51:46 +0100] "GET /page.html HTTP/1.1" 200 109
.... [17/Nov/2004:16:51:46 +0100] "GET / HTTP/1.1" 200 7959
.... [17/Nov/2004:16:52:01 +0100] "GET /page.php HTTP/1.1" 200 123
.... [17/Nov/2004:16:52:01 +0100] "GET / HTTP/1.1" 200 17253

Results in Opera 7.53:

.... [17/Nov/2004:16:39:39 +0100] "GET /page.html HTTP/1.1" 200 109
.... [17/Nov/2004:16:39:46 +0100] "GET /page.php HTTP/1.1" 200 123
why? :)


In fact all (graphical) browsers send two requests, one for the
document, one for the image. An empty URL denotes the current document,
so both requests are the same. The reason why in FF only one request for
the HTML file reaches the server is that static HTML documents are
cacheable, while PHP generated content is not cacheable by default (no
Expires or Last-modified header).

So the above results in FF are as I would expect, IE 5 is broken (wrong
resolving of empty URLs) and Opera also caches the php file (I'm
wondering why, maybe it depends on some configuration settings).

Try it with this line:

<img src="?" alt="No source specified">

and you will always see two requests in your logfile, because now the
URLs are different.

Micha
Jul 17 '05 #8
Martin Lucas-Smith wrote:

<link rel="stylesheet" href="<?=$URL_CSS_?>" type="text/css" />


What's the HTML output of this line?
I guess it is

<link rel="stylesheet" href="" type="text/css" />

I think perhaps the browser requests the "text/css" file "" (without the
quotes) and makes Apache (correctly?) run the script twice.

I agree that this is probably the reason. A link to "" is generally a link
to the same page, so Firefox is arguably correctly trying to download the
same page as a CSS file.
Martin
k


I think I have understood the reason of the behaviour but I think that
it's conceptually wrong.

In this case: <form action="">

the semplification "" = current page

is reasonable.

but it's not reasoneable that a page php with 3 null images (for a
stupid error :) ) runs x 3.

Imagine this situation:

A page, with 12 queries and 3 images null.
For this problem 12 queries become 36.
mulply it for number of users.... server dead :)





Jul 17 '05 #9
.oO(icui)
I think I have understood the reason of the behaviour but I think that
it's conceptually wrong.

In this case: <form action="">

the semplification "" = current page

is reasonable.
At least that's the definition of an empty URL. Some older browsers
interpret it differently (current directory instead of current page).
but it's not reasoneable that a page php with 3 null images (for a
stupid error :) ) runs x 3.
Of course it is. If you make such errors then you have to live with the
results. The browser just does what you tell him to do, nothing else.

If a document contains three URLs the browser will request them. If all
these URLs point to the same resource the browser will use a cached
version if possible. If the resource is not cacheable (like PHP-
generated documents by default) it sends three requests to the server.
That's simply how it works.
Imagine this situation:

A page, with 12 queries and 3 images null.
For this problem 12 queries become 36.
mulply it for number of users.... server dead :)


I don't consider that a problem, because it won't happen on a "normal"
website.

Micha
Jul 17 '05 #10
icui <ic**@noemail.it> wrote:

I think I have understood the reason of the behaviour but I think that
it's conceptually wrong.

In this case: <form action="">

the semplification "" = current page

is reasonable.

but it's not reasoneable that a page php with 3 null images (for a
stupid error :) ) runs x 3.
That's your opinion. It happens to be wrong. Do not expect standards to
change because you misunderstood them.
Imagine this situation:

A page, with 12 queries and 3 images null.
For this problem 12 queries become 36.
mulply it for number of users.... server dead :)


Right. Server dead because programmer stupid, or careless. You can't
program against stupidity.

What do you expect it to do? A null URL does not mean "nothing". It is a
shortcut for "the current page".
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Jul 17 '05 #11
icui wrote:
In this case: <form action="">

the semplification "" = current page


No; this is an exception. An empty URI reference in the
action attribute of a form, indeed any context where it is
'always intended to result in a new request', is a reference
to the base URI, which isn't necessarily computed from the
URI of the current page. 404 error pages, for example,
often explicitly set their base URI with the BASE element.

Ditch the folklore; RTFM, sec. 4.2:

http://www.ietf.org/rfc/rfc2396.txt

Cheers!

--
Jock
Jul 17 '05 #12
Michael Fesser wrote:
.oO(i-c-u-i)
----------------------------------------
page.htm

<img src="" alt="No source specified" />
----------------------------------------

----------------------------------------
page.php

<img src="" alt="No source specified" />
----------------------------------------

Results in IE 5:

... [17/Nov/2004:16:51:46 +0100] "GET /page.html HTTP/1.1" 200 109
... [17/Nov/2004:16:51:46 +0100] "GET / HTTP/1.1" 200 7959
... [17/Nov/2004:16:52:01 +0100] "GET /page.php HTTP/1.1" 200 123
... [17/Nov/2004:16:52:01 +0100] "GET / HTTP/1.1" 200 17253
[ ... ]
So the above results in FF are as I would expect, IE 5 is broken (wrong
resolving of empty URLs) and Opera also caches the php file (I'm
wondering why, maybe it depends on some configuration settings).


In fact IE is the only one getting it right, which makes for
a refreshing change.

--
Jock
Jul 17 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by beliavsky | last post: by
18 posts views Thread by Bryan Parkoff | last post: by
6 posts views Thread by keepyourstupidspam | last post: by
15 posts views Thread by Liviu | last post: by
Sheepman
10 posts views Thread by Sheepman | last post: by
10 posts views Thread by Jesse Burns aka jburns131 | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.