Blocked request is sent regardless
Categories
(DevTools :: Netmonitor, defect, P3)
Tracking
(Not tracked)
People
(Reporter: richard+bugzilla, Unassigned)
References
Details
Attachments
(3 files)
Steps to reproduce:
I added a request to the request block list in the developer tools.
Actual results:
The request is shown as blocked in the request list. However, the request is still dispatched to the server. This only happens in some cases. In most cases it works and the request is blocked. Each request is shown as blocked in the request list, regardless if it's blocked or not.
The requests in question are triggered by JS via XHR.
Expected results:
All requests to the blocked url should be blocked and never sent.
| Reporter | ||
Comment 1•3 years ago
|
||
Version: Mozilla Firefox 108.0b7 (64 bit) (Developer Edition)
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Lightly tested with a "random" website on Nightly 109, linux. Unable to reproduce after blocking with both GET and PUT and requesting via console with: xhr.open('PUT', '<page-path>'); xhr.send();
- Can you submit some http logs to necko@mozilla.com?
- Does this only happen with .ics PUTs?
- Does this only happen on localhost?
- How are you making the duplicate requests exactly?
Comment 4•3 years ago
|
||
I think this is a devtool bug.
We don't need the http log, but it'd be good to provide us a reliable way to reproduce this. Thanks.
| Reporter | ||
Comment 5•3 years ago
|
||
I attached a simple Python3 web server with some javascript to send XHR request. The bug can be reproduced very reliably using this setup. Run it via python3 ./server.py, open http://localhost:8080 in Firefox and block requests to http://localhost:8080/ping in the DevTools.
I was able to reproduce the bug 100% of times during my initial testing. It does not seem to be related to .ics PUTs.
Please let me know if you need further information about my repro code or the bug in general.
How does it work?
- Browser sends a XHR request to /ping once every second.
- Server logs the request to stdout and responds with "pong".
- Client logs the response to the browser console and also appends an element to body with a timestamp.
Expected behavior
- The web server should not log any incoming request because they are blocked.
- The browser console should not log any incoming responses because the requests shouldn't be send in the first place (hence no responses).
Actual behavior
- The network logs in DevTools shows that requests are blocked.
- The server logs incoming requests but errors on writing a response.
- The browser console does not log incoming responses and no elements are appended to the html body.
- => This indicates that requests are not blocked by DevTools. However, it seems that responses are blocked instead. They aren't read and the connection is closed.
Error logged by the server:
127.0.0.1 - - [03/Dec/2022 11:47:59] "GET /ping HTTP/1.1" 200 -
----------------------------------------
Exception occurred during processing of request from ('127.0.0.1', 33970)
Traceback (most recent call last):
File "/usr/lib/python3.10/socketserver.py", line 316, in _handle_request_noblock
self.process_request(request, client_address)
File "/usr/lib/python3.10/socketserver.py", line 347, in process_request
self.finish_request(request, client_address)
File "/usr/lib/python3.10/socketserver.py", line 360, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python3.10/socketserver.py", line 747, in __init__
self.handle()
File "/usr/lib/python3.10/http/server.py", line 432, in handle
self.handle_one_request()
File "/usr/lib/python3.10/http/server.py", line 420, in handle_one_request
method()
File "/home/richard/Code/firefox-bug-repro/./server.py", line 23, in do_GET
self.wfile.write(b'pong')
File "/usr/lib/python3.10/socketserver.py", line 826, in write
self._sock.sendall(b)
BrokenPipeError: [Errno 32] Broken pipe
----------------------------------------
| Reporter | ||
Comment 6•3 years ago
|
||
| Reporter | ||
Comment 7•3 years ago
|
||
| Reporter | ||
Comment 8•3 years ago
|
||
The bug is also reproducible on Firefox Nightly.
$ ./firefox --full-version
Mozilla Firefox 109.0a1 20221202212633 20221202212633
Updated•3 years ago
|
Comment 9•3 years ago
|
||
Thanks for the STR.
I could reproduce the issue. It looks like its related to Bug 1756770.
Lets keep and test both STR when fixed.
Updated•3 years ago
|
Comment 10•1 year ago
|
||
Hi Richard,
We recently landed a fix for this on Nightly, via Bug 1756770. Can you check if it fixed your problem?
Thanks!
| Reporter | ||
Comment 11•1 year ago
|
||
I just tested Firefox Nightly 129.0a1 (2024-06-19) (64-Bit) and the issue is fixed in this version.
Thanks for tackling this bug :)
Comment 12•1 year ago
|
||
Thanks a lot for checking! Let's close this bug then :)
Description
•