calling cancel() in on-modify-request should prevent the request to be sent to the server




12 years ago
11 years ago


(Reporter: Biesinger, Assigned: Biesinger)



Firefox Tracking Flags

(Not tracked)



(1 attachment, 2 obsolete attachments)

The request is sent currently. It shouldn't be.
oops, forgot to update that first comment in this testcase...
Created attachment 236163 [details] [diff] [review]

includes the correct unit test
Attachment #236163 - Flags: review?(darin)

Comment 4

12 years ago
Comment on attachment 236163 [details] [diff] [review]

Since we compile with logging enabled, why not compact that to only one LOG statement.  Just pass mCanceled as a parameter to the LOG output.

r=darin with that change
Attachment #236163 - Flags: review?(darin) → review+
Created attachment 236250 [details] [diff] [review]
patch v2

now with a single LOG statement
Attachment #236159 - Attachment is obsolete: true
Attachment #236163 - Attachment is obsolete: true
Checking in netwerk/protocol/http/src/nsHttpChannel.cpp;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,v  <--  nsHttpChannel.cpp
new revision: 1.294; previous revision: 1.293
Checking in netwerk/test/unit/head_http_server.js;
/cvsroot/mozilla/netwerk/test/unit/head_http_server.js,v  <--  head_http_server.js
new revision: 1.6; previous revision: 1.5
RCS file: /cvsroot/mozilla/netwerk/test/unit/test_httpcancel.js,v
Checking in netwerk/test/unit/test_httpcancel.js;
/cvsroot/mozilla/netwerk/test/unit/test_httpcancel.js,v  <--  test_httpcancel.jsinitial revision: 1.1
Last Resolved: 12 years ago
Resolution: --- → FIXED
Comment on attachment 236250 [details] [diff] [review]
patch v2

(this patch has r=darin on the previous attachment)

This is a low-risk patch to allow extensions to prevent requests to be sent to the server.
Attachment #236250 - Flags: approval1.8.1?

Comment 8

12 years ago
Comment on attachment 236250 [details] [diff] [review]
patch v2

We are just coming up on final release - we've lived with this behavior since 1.0 - and there are workarounds so 181 drivers would rather play it extra safe and not touch core code.  Great for the trunk - and thanks for tracking this down...
Attachment #236250 - Flags: approval1.8.1? → approval1.8.1-
OK, but I want to note that I don't think there's a workaround in the case that the extension wants to read the POST data before cancelling.

Comment 10

11 years ago
It seems that, this only works for cancelling the request for the main page, but not for parts of the page, e.g. images. Is there a workaround for this?
This should work for all requests. Can you file a new bug with a testcase? (note: images may be part of the imagelib cache, in which case it is possible that no HTTP request is made for them, so there's nothing to cancel here)

Comment 12

11 years ago
I did some more digging and the problem is not limited to images. I found out something really surprising. I'm not sure this belongs in a new bug report, so I'll report it here for now. Let me know if you want me to open a new report nevertheless. 

Here is the testcase: I have a simple page with some text and an image, which is being served by my own webserver (Apache 2.0.54 on Fedora). My user agent is Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0. I clear the cache before every experiment. I monitor the HTTP requests and responses from my webserver.

I register an observer for 'http-on-modify-request', and in the observe() method I do:
var httpChannel = subject.QueryInterface(Components.interfaces.nsIHttpChannel);

The surprising thing is the following: I can see an HTTP request for the main page (but not for the image) coming to my webserver, and it sending a 200 OK response back. However, the browser never displays the page; it's as if it ignores the response.

Could it be because the browser sends the request before I have a chance to cancel it (for performance reasons), but then realizes it should have never been sent and thus does not render the received page? 
Firefox 2 does not have this bugfix. You'll have to wait for Firefox 3.

Comment 14

11 years ago
I see. Thanks for the info, I didn't know that.
You need to log in before you can comment on or make changes to this bug.