I'm trying both chrome and Firefox, for one resource, Firefox does not make request to get it after downloading it once (I'm actually upgrading it), and firebug shows this line in response header
The request was resolved directly from the cache, so we have no response from the server. See below for the cached response.
However, chrome works fine. Is this a firefox bug or something?
The first download request in firebug
Related
I am attempting to write a Firefox extension which downloads files.
The website that I'm trying to download the files from requires cookies to be passed to GET requests, otherwise a 403 is returned.
I can visit the URL that I'm attempting to download the file from in the browser, and the file will load correctly, indicating that my cookies are correct.
I can also, using my extension, issue GET requests to an authenticated-only API from the same domain and receive the correct response (indicating that cookies are passed correctly).
However, when I attempt to download a file from a url using Firefox's downloads API (browser.downloads.download), the download fails (I get a 403), because the cookies aren't being passed. I have confirmed this with Charles Proxy.
The Mozilla Documentation says "If the specified url uses the HTTP or HTTPS protocol, then the request will include all cookies currently set for its hostname"; my url uses HTTP.
Why aren't the cookies being passed?
I'm using Firefox Developer Edition (68.0).
It was a Firefox bug in versions 67-69.
https://bugzilla.mozilla.org/show_bug.cgi?id=1555591
So I'm trying to create some scripts that have to run on a particular site protected by CloudFlare. I am getting one odd situation though:
Whenever I send a cURL request with the command line to that particular website (just a GET request), it reports a 503.
When I do the same request with a Firefox RESTED client, it reports a 200. - Running it in my browser executes the javascript protection as expected (so a 200 as well)
What can possibly be the trick to identifying a CURL vs a Firefox RESTED client-request, that both seem to do the exact same thing?
I'm using:
same IP
same User-Agent (in fact I tried mocking over 7 headers that my regular browser sends too, including Accept-Language Accept-Encoding and more)
Apparently when using the RESTED Firefox add-on, it uses all cookies that are currently in your firefox browser as well. One of these cookies identified my RESTED client as being valid
Somehow, we are able to make a cross origin XHR request on Chrome (latest stable) & Firefox without using CORS or anything of the sort. I am puzzled by this, hence this question.
Make an XHR Post Request to http://partychat-hooks.appspot.com/post/p_mwe2ztni with the data:
{body:"Some text"}
If you are on a Jquery enabled site, just type $.post("http://partychat-hooks.appspot.com/post/p_mwe2ztni",{body:"Hello World"}) on the console. SO has Jquery, so you can just press F12 now and paste this in your console.
The request goes from "Pending" to "cancelled" over in the network tab. The browser even gives us a warning about However, wireshark tells me that the request is actually getting made. (and is confirmed by a ping on the chatroom (join us at abhshkdz#im.partych.at)).
The following screenshots shows 3 things:
The request was made by JS
The browser aborted the request as it was a Cross-Origin Request w/o CORS. (Presumably an OPTIONS request should have been sent)
The popup on top-right shows that the request succeeded somehow.
Here is a screenshot of WireShark showing the Request response (served over Google AppEngine)
You can get the pcap file from here.
Also, notable is the fact that I don't see any OPTIONS request being made by the browser at all (which it should to check for CORS support).
Someone please help us solve this mystery.
Provided the request is a 'simple method' (GET/HEAD/POST) and the headers are all 'simple headers', then the browser can follow the 'simple' steps for the request, which don't include an OPTIONS pre-flight.
I'm using an angular service to GET a resource via a rest api. The server sets the ETag header to some value and it also sets Cache-Control: no-cache in it's response.
This works as expected using Firefox, but when I access the same app using Chrome, it is not sending the If-None-Match. I've tried on current Chrome dev and stable channels on both a Mac and an Ubuntu box, and it was the same on both, while Firefox was adding the If-None-Match correctly.
Now, there are other non-xhr/static resources that are fetched conditionally and all those requests correctly get a 304 NOT MODIFIED response.
Is there anything I can do to get more information about why Chrome is not sending the If-None-Match header only for XHR requests?
If you're issuing an Ajax query in Chrome over HTTPS, any certificate errors, such as using a self-signed cert on your API server, prevent the response from being cached. This seems to be by design.
Evidently a Chrome defect existed but was fixed in Webkit and made it into Chromium / Chrome around 2010.
Another question recommends setting the If-Modified-Since and If-None-Match headers manually using jQuery's ifModified: true and cache: true options. Unfortunately this won't over-ride Chrome's intended behavior to not cache HTTPS responses from a server with a self signed certificate.
Testing on a server with a valid signed SSL certificate solved the issue for me; Chrome received 304's for text/html content as expected, using the default jQuery AJAX methods.
I just wanted to check if my HTTP caching for my website is working especially since I moved to a CDN.
Now I used both Fiddler and Firebug and what I am seeing is that requests for ALL scripts and images on my page every time I navigate to it. Response code is 200.
If I open the page in Chrome, the developer tools also show me all these requests but Chrome also tells me that the requests are served from the Cache. Chrome requests are not listed in Fiddler (while FF and IE requests are).
My original assumption was that if Firefox or Internet Explorer get a file from their cache that request wouldn't show up at all in Fiddler.
I checked my caching headers and since Chrome behaved exactly like I expected I am asking myself if my assumption about Fiddler was wrong. Are FF/IE behaving differently when Fiddler is started? Is Fiddler showing cache hits?
As a network proxy, Fiddler is not able to show anything that comes out of the cache. If you see a request in Fiddler, then that request was sent over the wire.
One thing to keep in mind is that if you're refreshing the page (e.g. with the button or F5) then the cache can be bypassed; see http://blogs.msdn.com/b/ieinternals/archive/2010/07/08/technical-information-about-conditional-http-requests-and-the-refresh-button.aspx