Closed Bug 398249 Opened 17 years ago Closed 3 years ago

Javascript errors retrigger a request if response stream is still open (with Firebug add-on)

Categories

(Core :: General, defect)

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

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: glassofwine, Unassigned, NeedInfo)

Details

(Whiteboard: )

Attachments

(3 files)

HTTP Header log of access to page with JS error, when cookie is disabled
2.16 KB, text/plain
Details
Firefox 2.0.0.11 HTTP Header log of access to page with two faulty script sections, when cookies are disabled
3.21 KB, text/plain
Details
Firefox 2.0.0.11 HTTP Header log of access to page with two faulty script sections, when cookies are enabled
3.21 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

If a response to a request is being sent in chunks and if in the already sent parts a Javascript error occurs, while the response is not complete, the same request is being acquired again. The retriggered request will always be a GET, even if the original was a POST. 

There is surely no problem with <img src=""> or with a missing "return false;" in a href="javascript:...". There is also no dependency to other libraries like Struts (like mentioned in Bug 297071).

I can always reproduce this behaviour in Firefox 2.0.0.7 as well as in Internet Explorer 7.0.75730.11.

The error is quite serious as for our webapp, we cannot guarantee that customers will write Javascript-error-free templates and it could cause strange side-effects, like duplicate data, lost data,...

Reproducible: Always

Steps to Reproduce:
1. Take for instance the jsp-examples webapp bundled with Tomcat 5.5.
2. Copy the include folder within jsp-examples to myinclude
3. Add these lines somewhere on the top of the include.jsp (just a Javascript, which produces an error, as the method readCookie cannot be found):
<script type="text/javascript">
document.write(readCookie('Username'))
</script>
4. Import jsp-examples to Eclipse, connect the debugger to the running Tomcat server and set a breakpoint to the line:
<jsp:include page="foo.jsp" flush="true"/>
5. Call http://localhost:8080/jsp-examples/myinclude/include.jsp 
Actual Results:  
When you call the URL http://localhost:8080/jsp-examples/myinclude/include.jsp you will see that two threads are stopping at the breakpoint. If you fix the Javascript error or simply remove the script again, only one request is being sent. (The same happens also in Internet Explorer - just when the popup comes up, which asks if you want to debug the Javascript error, you should not press any button.) So this must be a problem with the Javascript engine.
Component: General → JavaScript Engine
Product: Firefox → Core
Summary: Jacascript errors retrigger a request if response stream is still open → Javascript errors retrigger a request if response stream is still open
Component: JavaScript Engine → General
QA Contact: general → general
Confirmed in 2.0.0.11, fixed in 3.0b3pre.

This is definitely critical as it can cause credit card payments to be repeated on shopping sites - we have had several cases of this.

I confirmed the following and provide a test script below:

1. triggered by a simple JS error such as:  <script type="text/javascript">blah;</script>

2. the duplicate request has no referer, but otherwise is an exact duplicate

3. if the doc is cacheable, the duplicate request is served from the internal cache - for non-cacheable, the web server gets the duplicate request

4. GET and POST both affected

5. HTTP and HTTPS both affected

6. Document form has no effect - XHTML and old style docs both affected

7. I created a test case - put this script on a site (tested with PHP5+Apache2) and you will see duplicate requests in the logs using 2.0.0.11.  Each click generates a unique URL so you can easily see the effect.  You will see this effect a lot more with HTTPS, because the internal cache will sometimes cache docs marked non-cachable, so on regular HTTP you will not always see the duplicate.

--------------------------------------------8<-------------
<?php header("Cache-Control: no-cache, must-revalidate");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); ?>
<html>
<head> <title>test</title> </head>
<body>

    TEST <?php srand(time()); $t=rand(); ?>
    <form method="post" action="/utils/t.php/<? echo $t; ?>">
        <input type="submit" value="POST <? echo $t; ?>" />
        <a href="/utils/t.php/<? echo $t; ?>">GET <? echo $t; ?></a>
    </form>

  <script type="text/javascript">
    blah;  // cause error
  </script>

</body> </html>
--------------------------------------8<----------

(In reply to comment #0)
> the same request is being acquired again.

To Benjamin Papez(bug opener):

Same problem as Bug 384222? See Bug 384222 Comment #14.
Check HTTP headers and HTML source which your application sends.
See Bug 384222 Comment #20 for LiveHTTPHeaders.

(In reply to comment #1)
> 1. triggered by a simple JS error such as: <script type="text/javascript">blah;</script>

To Versatilia Support:
  
Are you sure that the script error by undefined blah is really the trigger of double HTTP GET(or POST)?
Can you upload the test case and open URL to public?
To Versatilia Support:
Bug 387078(which was DUP'ed to bug 384222 once, and re-opened soon, but no response from bug opener for long time) looks to be same case as yours.
(In reply to comment #2)
> Same problem as Bug 384222? See Bug 384222 Comment #14.
> Check HTTP headers and HTML source which your application sends.
> See Bug 384222 Comment #20 for LiveHTTPHeaders.

No, its definitely not the same problem. Our HTML document is:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<meta name="robots" content="noindex,nofollow"/>
<title>Jahia Engine - Add Container</title>

I am sure that the script error retriggers the request. This is happening only if the response stream is still open and the chunk with the Javascript error is already sent to the browser. If I test the same with an error free script, the request is not being resent. The request is even resent multiple times if multiple script errors occur.
(In reply to comment #4)

Benjamin Papez, can you open URL of test page to public?

(in comment #0)
> 3. Add these lines somewhere on the top of the include.jsp (just a Javascript,
> which produces an error, as the method readCookie cannot be found):
> <script type="text/javascript">
> document.write(readCookie('Username'))
> </script>

When PHP, if "echo '<script type=...>...</script>';"(this returns HTML text) is called before any "header('HTTP_header_nam2: HTTP_header_data');" request (this is HTTP header request), data of header() request is not sent as HTTP header.
  (When this PHP case, the late "header('...');" becomes similar call to)
  ("echo '...';", so garbage text will usually appear.                  ) 
This kind of coding will always produce different result from programmer's expectation. 
Is your "Add these lines somewhere on the top of the include.jsp" done at correct place?

(in comment #0)
> If a response to a request is being sent in chunks and if in the already sent
> parts a Javascript error occurs, while the response is not complete, the same
> request is being acquired again. The retriggered request will always be a GET,
> even if the original was a POST. 
(in comment #4)
> I am sure that the script error retriggers the request. This is happening only
> if the response stream is still open and the chunk with the Javascript error is
> already sent to the browser.
(in comment #4)
> If I test the same with an error free script, the request is not being resent.
> The request is even resent multiple times if multiple script errors occur.

Flow sounds as follows.
(1) Main HTML with FORM(method=POST,action='URL').
(2) Submit form(with POST)
(3) HTML is returned (chunked)
    (some "<script>...</script>"s, which will produce JS error, are added)
(4) On each JS error while reading returned HTML(as response to HTTP POST),
    HTTP GET is issued to the 'URL'.

Did you check real HTTP header flow?
When HTTP GET caused by JS error, what is passed as query string?
Simple HTTP GET to the 'URL' with no query/flagment specicification?
What Cache-Control is specified by server?(by Apach, by user Script, by HTML)
HTTP GET with If-Modified-Since?

As seen in Bug 384222 Comment #18, when HTML is sent with "Content-Encoding: gzip", double HTTP GET doesn't seem to be issued when Bug 384222's case.
  (Because unzip is executed after receive of whole data,           )
  (I guess that whole HTML data is available in cache in this case. )
Because you say as follows, "Content-Encoding: gzip" is possibly a workaround.
> This is happening only if the response stream is still open
Can you use functions to gzip HTML in your JSP script and return the HTML with "Content-Encoding: gzip"? 
> Benjamin Papez, can you open URL of test page to public?

Yes, you can try these:

This one creates the script error and resends the request:
http://pol3.jahia.com/jspgen/myinclude/include.jsp

This one is the same without the script error and no resend happens:
http://pol3.jahia.com/jspgen/myinclude/noerr-include.jsp

>Can you use functions to gzip HTML in your JSP script and return the HTML with
>"Content-Encoding: gzip"? 

Basically we do not want to do that, but would like that the request is sent in chunks if it takes too long.
(In reply to comment #6)
> This one creates the script error and resends the request:
> http://pol3.jahia.com/jspgen/myinclude/include.jsp

Attached is HTTP Header log of access to the page(with JS error), when cookie is disabled. (1) Load the page, (2) CTRL+R (Reload)
Apparently only two HTTP GET is issued by Seamonkey. "double HTTP GET due to JavaScript error" can not be observed.

(A) As seen in HTTP log, session id is sent by HTTP header.
When cookie is disabled by user, browser won't send cookie. So when cookie is disabled by user, any request from client looks to be new session request for server side application.

(B) When cookie is enabled by user, if the session cookie data(which is sent by HTTP header) is modified by JavaScript at client(generated or sent by the application intentionally), and if the application expects the modified cookie data from browser, inserted JavaScript error may stop execution of logic for required cookie data modification.
In this case, next request from browser can be seen as new request from client for the application.

One of above two cases, isn't it?
When JavaScript error has relation to problem, please note following.

>(Case-1)
> <script> var x=func1(); </script>
> <script>
>   function func1() { ... }
>   function func2() { ... }  => Causes Syntax Error
> </script>
>(Case-2)
> <script> var x=func1(); </script>
> <script>
>   function func1() { ... }
> </script>
> <script>
>   function func2() { ... }  => Causes Syntax Error
> </script>

When Case-1, func1 is not defined, then "var x=func1()" fails.
This is because both func1 and func2 are declared in same scope.
When Case-2, func1 is defined, and "var x=func1()" is successful. 
This is because func1 and func2 are declared in different scope.
So, when Case-1, required logic of func1 can not be executed, if syntax error of func2 exists. But when Case-2, func1 can be executed even if syntax error in func2 exits.

If required logic of func1 is not executed, browser's behavior becomes very different one from Web application designer's expectation.
If JavaScript logic is executed partially, result is unpredictable.
Is above issue involved in your problem?

(In reply to comment #10)
> Firefox 2.0.0.11 HTTP Header log of access to page with two faulty script sections

(Your HTTP header log with localhost:8080)
> http://localhost:8080/examples/jsp/myinclude/include.jsp
> Cookie: JSESSIONID=6949B1E737B58E397B4E47CAADAE3F99; settings_showservers_nodeExpansion=Icaeea2a98d3e5e3f2ea69919a2d4f672%2CIdb71a8bcd8e49d441ebaec615fa58c1b; WT_FPC=id=195.16.248.219-1809735232.29860908:lv=1200314171962:ss=1200314013071; dashboard_index_doRefresh=60; advisors_add_nodeExpansion=I9446a98ad14416153cc4d45ab8b531bf%2CI7146a60667b422e69fd050fe1df6859a; CP=null*
>(response)
> HTTP/1.x 200 OK
> Server: Apache-Coyote/1.1
> Content-Type: text/html

(HTTP header with test site you opened to public)
> http://pol3.jahia.com/jspgen/myinclude/include.jsp
> Cookie: JSESSIONID=F0CB83113C40E6F8A570051E8FBB0863
>(response)
> HTTP/1.x 200 OK
> Server: Apache/2.2.3 (Debian) mod_jk/1.2.18 mod_ssl/2.2.3 OpenSSL/0.9.8c
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Content-Type: text/html;charset=ISO-8859-1

Same test case? Same application?
Can you observe "HTTP GET on each JavaScript error" with test site you opened to public?
Strange, I also submitted a comment along with my uploaded files, which somehow disappeared. 

(In reply to comment #11)
> Same test case? Same application?
> Can you observe "HTTP GET on each JavaScript error" with test site you opened
> to public?
 
I wrote that I also installed Seamonkey, with which I could not recreate the problem. Versatilia Support also commented that in Firefox 3 the problem seems to be solved.

So the problem is recreatable only with Firefox 2.0.0.11 and also with Internet
Explorer 7.0.75730.11.

The above attachments are not exactly from the same test case, but from one I created locally, where I had two <script> sections and both having an error. Each <script> section with an error triggered a resend of the request, so thats why there are in total three requests. If there are two script errors in the same <script> section this triggers just one resent. 

It does not matter if cookies are enabled or not. 
(In reply to comment #12)
> So the problem is recreatable only with Firefox 2.0.0.11 and also with Internet
> Explorer 7.0.75730.11.

I couldn't/can't see your problem with any of Seamonkey 1.1.7. Firefox 2.0.0.11, Firefox trunk(2008-01-27-04 build) at following page. (added extension is LiveHTTPHeaders only.)
> http://pol3.jahia.com/jspgen/myinclude/include.jsp

You say that you can see the problem with test page at pol3.jahia.com too, using your Firefox 2.0.0.11 and IE 7?
Browser sniffing with User Agent string is done by your application at localhost:8080? If yes, same HTTP header/cookie/HTML/script will be sent to Seamonkey and Firefox 3 beta?
Can you see problem with new profile, Firefox 2.0.0.11, localhost:8080? 

FYI.
Extension + "View Page Source" can be a culprit when Mozilla family, because "View Page Source" issues HTTP GET if page data is not available in Cache.
 (0) Set browser.sessionhistory.max_total_viewers=0
     (in order to exclude bfcache related phenomenon)
 (1) Load pol3.jahia.com/jspgen/myinclude/include.jsp in a tab => HTTP GET
 (2) Clear Cache
 (3) "View Page Source" at tab of the test page => HTTP GET again
If extension issues "View Page Source" internally when JavaScript error occurs, it'll possibly cause new HTTP GET when whole page data is not available in Cache.
Sorry but I can say nothing about IE7 case.
I have now started "firefox -p" to create a new profile without any addons activated. I really could not reproduce the error.

Then I one-by-one installed my addons from the default profile and found that the error behaviour is being caused by Firebug 1.05. 

I opened a new issue ticket here: http://code.google.com/p/fbug/issues/detail?id=448&start=200

Don't know yet what caused the same problem in IE7.

Thanks for helping out with your guesses and keep up developing my favourite browser.

Thanks,
Benjamin
(In reply to comment #15)
> the error behaviour is being caused by Firebug 1.05. 

I guess scenario is as follows.
 (1) Original HTTP GET, and HTML is returned with chunked
 (2) While HTTP GET is still in progress, top part of chunked HTML is processed,
     and JavaScript error occurs, and Firebug request HTML source data.
     I guess it is internal "View Page Source" request.
 (3) Firefox tries to pass HTML source data to Firebug. But, because HTTP GET is
     still in progress, cache entry is not filled yet, then new HTTP GET is
     requested and queued.
 (4) When original HTTP GET completes, queued HTTP GET by internal "View Page
     Source" is executed, even though required data for internal "View Page
     Source" is available at this stage by original HTTP GET completion.

Possible solution.
(a) Inhibit or postpone "View Page Source" until page load completion
(b) If multiple HTTP GET to same URL are queued, wait for completion of previous
    request, and issue HTTP GET only when it is really required.
    - Previous HTTP GET fails
    - Chached data by previous request is expires(e.g. max-age=0)
    ("Whether issue HTTP GET or not" is decided at step (3), I think.)
 
Possible workaround in your case.
  Return HTML with "Content-Encoding: gzip".
Can you test this with Firebug?
I can see problem at last! (I installed Firebug)
Could you add "Firebug" in bug summary for ease of search, please.

>(Your comment in Firebug forum)
> The retriggered request will always be a GET, even if the original was a POST

FYI.
I could see multiple POSTs by Firebug when script error at top of <head>.
> <html><head><script>...</script></head><body>4000 of <p>...</p></body></html>
When this HTML was returned as response to POST request, dupulicated request was also POST request(same content as original POST request).
And, when 2 or more concecutive script errors in <head> (then consecutive POST requests), Firefox 2.0.0.9 froze.
(Because of freeze, it was impossible to see HTTP header by LiveHTTPHeaders.)
(So multiple POSTs was checked by server side log written by PHP script.    )
Summary: Javascript errors retrigger a request if response stream is still open → Javascript errors retrigger a request if response stream is still open (with Firebug plugin)
Summary: Javascript errors retrigger a request if response stream is still open (with Firebug plugin) → Javascript errors retrigger a request if response stream is still open (with Firebug add-on)
Based on previous comments: confirming, 1.8 branch only.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [firebug-p1]
Version: unspecified → 1.8 Branch
FYI.
I've met Bug 430155, an enhancement request. If it'll be fixed, solution of the "double post" issue by Firebug side enhancements/changes will become possible.
See Bug 430155 Comment #6. 
Fixed on 3.0.4, FF2 not a Firebug priority
Whiteboard: [firebug-p1] →

Are you still able to reproduce this issue or can it be closed?

Flags: needinfo?(m-wada)

Marking this as Resolved > Incomplete due to the lack of info.
If anyone is able to reproduce this issue re-open it or file a new bug.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: