Cache contents cause automatic URL rewriting
Categories
(Core :: Networking: Cache, defect, P2)
Tracking
()
People
(Reporter: sam, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged][necko-priority-review])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Steps to reproduce:
Install pi-hole docker on a remote ip. Log-in, browse the admin interface. Replace docker image with adguard-home docker, at same ip address. Disable all address-bar suggestions. Clear history. Tried to go to the adguard-home webinterface at http://$IPADDR.
Actual results:
Firefox sends http request for http://$IPADDR/admin. This returns an error, as that url doesn't exist on the adguard-home webserver (but did exist, and was accessed on the pi-hole container)
Expected results:
Firefox sends the http request to http://$IPADDR as typed.
Reporter | ||
Comment 1•1 year ago
|
||
Clearing history and restarting in "safe mode", did not fix the issue. Clearing the cache did. Browser console logs showed the HTTP GET request going to the http://$IPADDR/admin with no reference to the original contents of the URL bar, wireshark logs also show nothing about the original URL. accessibility.blockautorefresh was set to true to ensure there was no redirection.
Comment 2•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Updated•1 year ago
|
Comment 3•1 year ago
|
||
History is not responsible for caching redirects and any other network state. The address bar only uses history, so moving this to Networking:Cache.
Hi Samuel,
Can you provide http logs? You can use the about:logging
to either make a profile or log to file. You may want to email to necko@mozilla.com
for privacy reasons.
Reporter | ||
Comment 5•1 year ago
|
||
I am travelling right now and don't have access to that machine. I will send these over when I get home.
Comment 6•1 year ago
|
||
I think we've had bugs like this before.
I think what's going on is that you have a HTTP redirect from / to => /admin with the wrong caching headers that make the redirect be cached for an unreasonable amount of time.
This is most likely a problem caused by the server. I expect it also happens in other browsers?
Updated•9 months ago
|
Description
•