I am trying to cache some images and using the DevTools of MS Edge to analyze the network.
The URL should return only the image via readfile($image) and I see the image correctly in the browser.
Response Headers:
HTTP/1.1 200 OK
Date: Mon, 25 May 2020 19:18:56 GMT
Server: Apache/2.4.38
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: max-age=86400
Pragma: no-cache
Debugbar-Time: 1590434336
Debugbar-Link: https://blog.casa.spiti/?debugbar_time=1590434336
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: image/jpeg
The Network Tab of the Chrome Dev Tools shows document for the image.
Questions to this output:
What is this expire date of 1981? How do I change it?
Is this the reason why the image is not cached?
Why is the image being indicated as document? Is it because I use readfile()?
Impossible to answer without seeing your server config.
Shouldn’t be, cache-control is used in preference to Expires.
If you are loading the image directly in the browser it shows as document - even if it’s an image. That image is the document in that case. If you load the image as part of an HTML document, then it will show as Image in Dev Tools.
Related
I am using Jmeter 5.4.1 version, my API is of oauth1.0 type. When I ran my api through postman , it gave my proper json response for example an proper id, but the same api when ran through jmeter gives 200 response code but giving details of server and connection in response body and not the reponse that is expected(a proper id).
Below is the response :
HTTP/1.1 200 OK
Server: nginx/1.14.0 (Ubuntu)
Date: Wed, 12 May 2021 12:33:10 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: PHPSESSID=eqvp0l22u2jo30moqn194meugp; expires=Wed, 12-May-2021 13:33:10 GMT; Max-Age=3600; path=/; domain=dev.moorup.no; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
X-Frame-Options: SAMEORIGIN
Cache-Control: no-store
enter image description here
You're looking at Response Headers tab of the View Results Tree listener therefore you're seeing the HTTP Response Headers
Just switch to Response Body tab and you will be able to see "raw" HTML Response and several options of rendering it:
Also be aware that it is possible to convert your Postman scripts to JMeter, for OAuth you will still have to do some correlation, but for the main logic record and replay should work more or less fine
I work at a company that makes a web publication software. Yesterday I've stumbled upon the strange bug with opening links from a flash. The link was to a page on linkedin.com site, but maybe it's not the only case.
Here is a test publication:
http://cdiem.cld.bz/Link-test
(Click the "Product guide" text, there is the link to a page on linkedin.com)
For some reason it opens as a plain text in Chrome and Opera (and maybe other Chromium-based browsers), but works fine in Firefox and IE.
It also works fine from HTML version of the publication (disable Flash plugin to see it). And it also works fine if you just reload the page.
My guess is that it has something to do with the X-Requested-With header field, cause it's the only thing I found that differs between the HTTP request from Flash and HTML versions of publication:
X-Requested-With:ShockwaveFlash/16.0.0.305
Could anyone give any advice on that?
I think that you are right about X-Requested-With.
Take these two tests that I did using hurl.it where you can test HTTP requests :
First test : just request our page.
Request headers :
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: runscope/0.1
Response headers :
Cache-Control: no-cache, no-store
Connection: keep-alive
Content-Encoding: gzip
Content-Language: en-US
Content-Length: 6156
Content-Type: text/html;charset=utf-8
Date: Thu, 05 Mar 2015 21:10:50 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
...
Here we can see very clear that server has sent a text/html content.
We do the same test but we will just add the X-Requested-With header.
Second test : request our page with X-Requested-With header.
Request headers :
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: runscope/0.1
X-Requested-With: stackoverflow_test
Response headers :
Cache-Control: no-cache, no-store
Connection: keep-alive
Content-Encoding: gzip
Content-Language: en-US
Content-Length: 3602
Content-Type: text/plain;charset=UTF-8
Date: Thu, 05 Mar 2015 21:21:06 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
...
This time we can see that the server has sent a text/plain content.
So it's clear that the server is changing the Content Type to text/plain when receiving a X-Requested-With header which is sent by Flash Player PPAPI (used in Chrome and Opera) like you can see here.
Hope that can help.
I am using php readfile to send a file to the browser. Its is an image file. Howver the browser downloads it, instead of displaying it.
This is the response header:
HTTP/1.1 200 OK
Date: Tue, 15 Jan 2013 14:11:46 GMT
Server: Apache
X-Powered-By: PHP/5.3.18-nmm1
Content-disposition: attachment; filename=test.jpg
Content-Length: 20599
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: image/jpeg; charset=binary
Why doesnt it display?
The bad guy is this line:
Content-disposition: attachment; filename=test.jpg
Try to remove it in order to show the image in the browser.
Alternatively, use a small html file, as this is the way a browser is supposed to work ;)
I have lot of small images (of sizes ~3kb or so) and lot of css and js files. After the first request tey are getting cached on the browser, but when I reload the page the browser is trying to check the freshness of the cached content (by setting the If-Modified-Since etc) and gets the response 304 not modified. Each of this validation request seriously increase the page load time (say 20 time 300ms).
How can I cancel this cache freshness check with the server from the browser? How can instruct the browser to use local cached files/images for certain time (say 1 hour) without re-validating or checking the freshness of the local cache with the remote server for every reload with that time period?
sample small image fetch header details below [using rails 3.1, on heroku]:
Response Headers
HTTP/1.1 304 Not Modified
Server: nginx/0.7.67
Date: Thu, 10 Nov 2011 17:53:33 GMT
Connection: keep-alive
Via: 1.1 varnish
X-Varnish: 1968827848
Last-Modified: Tue, 08 Nov 2011 07:36:04 GMT
Cache-Control: public, max-age=31536000
Etag: "5bda917d22f8a144c293f3f19723dbc6"
Request Headers
GET /assets/icons/flash_close_button-5bda917d22f8a144c293f3f19723dbc6.png HTTP/1.1
Host: ???.heroku.com
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://???.heroku.com/
Cookie: ???
If-Modified-Since: Tue, 08 Nov 2011 07:36:04 GMT
If-None-Match: "5bda917d22f8a144c293f3f19723dbc6"
Cache-Control: max-age=0
This line:
Cache-Control: public, max-age=31536000
is telling the browser to not ask for updates for a long time, and store the files in a publicly accessible cache (which hear means public to the local machine - not the general public). Your browser should therefore not really be re-checking those files. Have you tried another browser to verify this behaviour exists elsewhere?
Saying all of this though, considering that your files are coming from the varnish cache and not your dyno, and are being returned as HTTP 304, 300ms for 20 files sounds like a very long time. However, This should be barely perceptible to the user.
I use Fiddler to debug my application. Whenever the response is compressed by server, instead of decompressed response, Fiddler shows unreadable binary data:
/* Response to my request (POST) */
HTTP/1.1 200 OK
Server: xyz.com
Date: Tue, 07 Jun 2011 22:22:21 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.3.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Encoding: gzip
14
����������������
0
How can I get the response decompressed?
I use fiddler version 2.3.4.4 and just noticed that in the Inspectors tab ("Raw" sub-tab), above the response section (in case of gzip-ed response), appears "Response is encoded and may need to be decoded before inspection. Click here to transform."
If you click on that, the response becomes readable.
The settings are pretty much the default, I just installed Fiddler and did not change anything.
If you don't want to have to click per response as in the accepted answer, using the menu, click Rules -> Remove All Encodings.
From the fiddler faq
Q: I like to navigate around a site then do a "search" for a text on all the logged request/responses. I was curious if Fiddler automatically decompressed gzipped responses during search?
A: Fiddler does not decompress during searches by default, since it would need to keep both the compressed and decompressed body in memory (for data integrity reasons).
In current versions of Fiddler, you can tick the "Decode Compressed Content" checkbox on the Find dialog.
Here is a link to the site
http://www.fiddler2.com/fiddler/help/faq.asp