Closed Bug 387078 Opened 18 years ago Closed 5 years ago

Double calling of serverside PHP function(HTTP GET is issued twice upon Shift+Reload, if <script src=""> exists)

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1299373

People

(Reporter: rbrilus, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 In one of my PHP scripts I have a function that clears temporary files (uploaded files and MySQL dumped files) so that a user can start with a clean repository. This function gets called once during the execution of the script (controlled by an IF statement and control variable) when the control variable is set to null/undefined. In IE 7 and Opera 9 this function is only called once (as it should be) but in FF 2 it gets called the time that it should be plus every time this script is executed. There are 4 stages of this script and it should only be called once. It, however, gets called 5 times in FF; on every call to the script and the once that the script actually calls this function. Reproducible: Always Steps to Reproduce: 1. Login into system (http) 2. Got to specific page 3. Use the script as required The following is a log listing of the calls to the function with the time of the call (the ones marked with an * are the correct call): Firefox 2.0.0.4 - sessionId = "102f3e26af3bfd312db18cef3850b5c4", formAction = "/vpbl/blacklistAdminEdit.php?formAction=", timeStamp = "Thu, 05 Jul 2007 14:01:45 +0200" * sessionId = "102f3e26af3bfd312db18cef3850b5c4", formAction = "/vpbl/blacklistAdminEdit.php?formAction=", timeStamp = "Thu, 05 Jul 2007 14:01:45 +0200" sessionId = "102f3e26af3bfd312db18cef3850b5c4", formAction = "/vpbl/blacklistAdminEdit.php?formAction=", timeStamp = "Thu, 05 Jul 2007 14:01:48 +0200" sessionId = "102f3e26af3bfd312db18cef3850b5c4", formAction = "/vpbl/blacklistAdminEdit.php?formAction=", timeStamp = "Thu, 05 Jul 2007 14:01:50 +0200" IE 7.0.5730.11 - * sessionId = "b87d4fe99fb21d95426a8044d5e282ce", formAction = "/vpbl/blacklistAdminEdit.php?formAction=", timeStamp = "Thu, 05 Jul 2007 14:03:33 +0200" Opera 9.21 * sessionId = "7347fbd53a6a09c6b7e41fd1a9d33160", formAction = "/vpbl/blacklistAdminEdit.php?formAction=", timeStamp = "Thu, 05 Jul 2007 14:05:09 +0200" I use the following LAMP stack: Linux 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:08:39 EDT 2005 i686 Apache/2.0.54 (Unix) PHP 5.2.3 MySQL 5.0.14 i686 PC-Linux-GNU
Same phenomenon as Bug 384222?
It would certainly appear to be similar, as I do have international (non 7bit) characters in these pages (it's got English and Portuguese words and international country names in it).
It is the problem with charset encoding, I add <meta http-equiv=\"Content-Type\" content=\"text/html; charset=iso-8859-1\" /> to the pages and now it works. So, mozilla certainly has a problem with charsets and the way they are interpreted.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Sorry, that didn't help, I forgot I had already forced a work-around for the function call.
Resolution: DUPLICATE → INCOMPLETE
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
> Firefox 2.0.0.4 - > sessionId = "102f3e26af3bfd312db18cef3850b5c4", formAction = > "/vpbl/blacklistAdminEdit.php?formAction=", timeStamp = "Thu, 05 Jul 2007 > 14:01:48 +0200" Oh, form was involved. Get HTTP header log, using one of next. a. http://livehttpheaders.mozdev.org/index.html b. http://www.mozilla.org/projects/netlib/http/http-debugging.html See Dependency tree for meta Bug 288462. Was similar phenomenon reported?
To Richard(bug opener): Does your problem still remain?
To WADA: After reinstating all of the problem code (I had a work around implemented), I can safely say that the bug still exists, even in 2.0.0.11.
Because form is involved in your case, returned result for GET or POST is also involved in addition to main HTML. (1) URL typed => HTTP GET for main HTML(workaround is effective) with FORM (2) Submit => HTTP GET(or POST) to action URL in the FORM (3) Result HTML is returned. (Q1) Is the workaround effective on HTML at step 3 too? (Q2) Which method is used for form? GET? POST? When POST, if user do Reload operation after step (3), and if reply OK for confirmation, double POST can occur. This phenomenon can be observed after comment posting to bugzilla.mozilla.org. (When bugzilla.mozilla.org, "Air Collision" message will probably be returned.) Is this the case?
By some luck I believe I managed to work out what is going on and why. In my code I have a function to set up the initial page with the standard HTML tags including css file and js file inclusions, via variables. At the time I had no conditional based on whether these variables actually contained values (URL to the css and js files). In some cases I would not have a value in the js var but would still echo the <script src...> tag a blank src. Under these conditions firefox would encounter the blank src and revert to calling the same php script again, rather than simply ignoring the blank js declaration. I have since solved my problem by implementing a simple "if null" conditional but I still feel that the browser itself should be able to simply ignore the blank js declaration (as all the other browsers do).
> <script src...> tag a blank src. AFAIR, (a) <script id="scr1" src=""> and src="..." by JavaScript loads the script because of not-loaded-yet status, but (b) <script src="abc"> and src="def" by JavaScript doesn't load "def" because of already-loade status. So, if other JavaScript code executes document.getElementById("scr1").src="", I guess HTTP GET to current URL is issued because src="" means current URL. "Such PHP script logic error exists" means "other logic error is exists" in many cases. If <script>document.getElementById("scr1").src="";</script> is generated in addition to <script id="scr1" src=""> by your PHP script, above situation can occur. Other case. "Such PHP script logic error exists" means "other logic error is exists" in many cases. And it can produce <script>JavaScript statement which produces JavaScript error;</script>. In this case, if Firebug is used and some feature of Firebug is enabled, HTTP GET to current URL by Firebug can occur upon JavaScript error (Bug 398249). Do you use Firebug?
I simply have the following code: echo " <script language=\"javascript\" src=\"".$jsFile."\"></script>\n"; Where $jsFile may, on some occasions, equal "". In all other browsers that I have tested the result if $jsFile = "" is to do nothing but in firefox it loads the current URL. Please note I do not have firebug installed and I have tested this in a firefox with zero add-ons installed.
I checked with very small HTML file. > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> > <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Test</title> > <script id="scr1" language="javascript" src=""> > </script></head> >(snip) I couldn't observe double HTTP get, but I got next error. > Error: syntax error > Source File: file:///C:/wada/HP/HP-KDDI/test/script-src-null-2.htm Line: 1 > Source Code: > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> Firefox/SeaMonkey looks to use HTML itself(data of current URL) when <script src="">, according to HTML spec/RFCs about URI(URL). Your case is probably very large HTML. When script loader is invoked for <script src>, whole HTML data is not downloaded yet(not held in cache). It's similar situation to Bug 398249(Firebug tries to view source, and HTTP GET because not help in cache yet) I guess HTTP GET by script loader is issued for current URL in this case. AFAIR, HTTP GET is not issued to current URL for <img src=""> by Firefox/SeaMonkey. And quirks is done for <form action=""> with <BASE="...."> (form is sent to current URL instead of BASE+""). If you think it's important problem and compatibility with other browser is mandatory in this case, open separate bug for it, please.
I've searched B.M.O for 'script src=""'. > Bug 374023 Inclusion of <script src=""></script> makes Mozilla load page twice Status: RESOLVED DUPLICATE of bug 225554 > Bug 225554 page loaded twice if contains <img HEIGHT="5" WIDTH="100%" SRC=""> > Status: RESOLVED DUPLICATE of bug 444931 > Bug 444931 img src="" causes un-needed(?) network fetch > Status: RESOLVED FIXED (on 2008-08-08) <script src=""> case of Bug 374023 looks to be lost by repeated duping... Because next bug exists, HTTP GET seems to be still issued for <script src="">, as you said. > Bug 484383 src="" in <noscript> tag requested when Javascript is enabled.
I checked next case(two <script src="">). > <html><head><script src=""></script></head> > <boby><script src=""></script></body></html> (Test result with Firefox 3.5) (0) Clear cache (1) Initial load : One HTTP GET only, and 200 (2) Reload : Two HTTP GET with If-Modified-Since, and two 304 Not-modified (3) Shift+Reload : Three HTTP GET, and three 200 Did you use Shift+Reload(Shift+Ctrl+R, Shift+F5) in your test? Probably DUP of Bug 497665. See also Bug 502517, Bug 502556(DUPs of Bug 497665.)
(In reply to comment #9) > the browser itself should be able to simply ignore the blank js declaration (as all the other browsers do). Does other browsers really ignore <script src="">? Double meaning text(can be interpreted as both HTML and JavaScript properly) becomes impossible, if <script src=""> is ignored. I think they simply doesn't issue HTTP GET because that HTTP GET is already requested to the URI or already held in cache. (i.e. Bug 444931 doesn't exist since initial. Bug 497665 won't occur.) Is it wrong? If tries to process HTML source as text of <script>, at least two error can occur. (a) Incorrect content type for <script src> (Content-Type: text/html) (b) If tries to analyze as JavaScript, syntax error like comment #12 occurs. No other browser issues error message for a) or b)? Note: (a) always occurs, and (b) always occurs except for "Double meaning text". So I think ignoring of { <script src=""> without <BASE> } or { (<BASE>+src=...)==My own URL } is reasonable, even if "Double meaning text" becomes impossible.
(In reply to comment #14) > Did you use Shift+Reload(Shift+Ctrl+R, Shift+F5) in your test? Yes, I believe I did, as I always do this while developing to force a total refresh.(In reply to comment #15) (In reply to comment #9) > Does other browsers really ignore <script src="">? They certainly seem to do this and in my mind it makes sense to do so. With a <script> tag you have two options, (a) load the file specifically pointed to via the `src` attribute or (b) load the code contained between the <script>`code`</script> tags. Since having a src="" is the same as not declaring a `src` attribute declaration at all the browser should thus ignore the `src` attribute and move onto the `code` portion. Since one general either uses the `src` attribute or the `code` (but not both) if there is no `src` and no `code` then there is nothing to be done. This is certainly the behaviour of IE 7+ and Opera 9+. I'm not saying that this does not throw an exception internally to the browser (this I would not know), but there is no exception thrown to the user (i.e. the page functions as it should do).
(In reply to comment #16) > > Did you use Shift+Reload(Shift+Ctrl+R, Shift+F5) in your test? > Yes, I believe I did, as I always do this while developing to force a total refresh. Closing as DUP of Bug 497665, adding "<script src=""> in bug summary for ease of search. Below is list of bugs which has src="" in bug summary. For <script>, it seems "double get" issues only except one crash. There is no bug for src="" in <script> itself. If next html, confusing "syntax error 'var xxx;'" appears at Error Console :-) > <html><head><script src=""></script><script>var xxx;</script></head> I'll open bug for this funny phenomenon first. > Bug 27235 DUPL Browser crashes when JavaScript writes a <SCRIPT SRC=""> tag > Bug 71262 FIXE Add support for <stylesheet src=""> to XBL > Bug 71597 FIXE <other:stylesheet src=""/> works too... > Bug 114528 FIXE empty <img src=""> tags cause crash on 0.9.4 branch. > Bug 141184 NEW img src="" does not authenticate when page was loaded as file > Bug 225554 DUPL page loaded twice if contains <img HEIGHT="5" WIDTH="100%" SRC=""> (empty src attribute) > Bug 270866 DUPL browser does not omit image src="" resulting in requesting the same page twice > Bug 276287 DUPL <img src=""> creates spurious server hits > Bug 284503 DUPL HTML tag img src="" causes request to submit multiple times to the server. > Bug 301607 DUPL <xf:hint> src="" attribute not working > Bug 368980 DUPL src="" in images make FF to send double request on server > Bug 374023 DUPL Inclusion of <script src=""></script> makes Mozilla load page twice > Bug 374777 DUPL When rendering an <img> tag with an empty src attribute (<img src="">), Firefox instead loads the page containing the empty tag as the image source. > Bug 433481 DUPL tag <img src=""> will due to load current url again > Bug 444931 FIXE img src="" causes un-needed(?) network fetch > Bug 448620 DUPL html page with an img src="" causes to load the page twice (second time call seems to be executed inside the browser) > Bug 451429 DUPL a img with empty src (src="") causes double request of the page > Bug 484383 NEW src="" in <noscript> tag requested when Javascript is enabled.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago → 15 years ago
Resolution: --- → DUPLICATE
Summary: Double calling of serverside PHP function → Double calling of serverside PHP function(HTTP GET is issued twice upon Shift+Reload, if <script src=""> exists)
There is no way this is a duplicate of 497665. That has to do with images, not <script src="">.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(In reply to comment #18) > There is no way this is a duplicate of 497665. That has to do with images, not > <script src="">. But Bug 374023(<script src="">) was closed as DUP of Bug 225554(<img src=""), and Bug 225554 was closed as DUP of Bug 444931(<img src="")... DUPing of Bug 374023 to Bug 225554 was incorrect action? Or care for Bug 374023 case(<script src="">) was lost while fixing Bug 444931? Should we re-open Bug 374023 because Bug 374023 is not resolved yet even after DUP'ed bug was fixed? Or should we open separate bug(similar to Bug 497665) for <script src=""> case, for remaining issue even after fix of Bug 444931, because existing Bug 497665 is for image only?
FYI. I've opened Bug 506286 for phenomenon of Comment #12.
I've re-opened Bug 374023 to know what action is needed for double HTTP GET by <script src=""> case. Changing to NEW, because bug opener and me could still observe double HTTP GET by <script src="">.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → RESOLVED
Closed: 15 years ago → 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.