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
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 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.
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 have this server response for a file that I want not to be cached from the browsers. The response has two cache control headers.
Cache-Control: no-cache, no-store, must-revalidate (which is what I want and)
Cache-Control: private (which is appended by default from netscaler and the server side guys tell me they cannot remove it)
My question is which one will prevail?
HTTP/1.1 200 OK
Date: Mon, 20 Jan 2014 15:29:53 GMT
Server: Apache
Last-Modified: Fri, 17 Jan 2014 16:50:54 GMT
ETag: "682-4f02d58643780"
Accept-Ranges: bytes
Cteonnt-Length: 1666
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTR STP IND DEM"
Keep-Alive: timeout=5, max=1000
Connection: Keep-Alive
Content-Type: text/javascript
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Cache-Control: private
Content-Encoding: gzip
Content-Length: 716
As per RFC2616, setting the same header multiple times should be equivalent to setting it once with all values separated by comas.
Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma.
So in your case, it would be equivalent to
Cache-Control: no-cache, no-store, must-revalidate, private
private will just further prevent the response to be cached by a proxy between the server and the browser, so it shouldn't have any adverse effect.
Having researched a similar issue for a client, I can tell you from my own experience that, if this content is being served through a Citrix NetScaler and compression has been enabled, anything with a content-type of text will have a Cache-Control: private value set by the NetScaler. How you're getting two entries is beyond me. However, Yolanda's answer is most likely correct. The only reason for the caveat is that RFC2616 was superseded in 2014. (See https://www.w3.org/Protocols/rfc2616/rfc2616.html)
Regarding the NetScaler adding/replacing the Cache-Control header, it appears that it can be turned off; You just have to know how. Had to open a case with Citrix to learn about CTX124717 (FAQ:Preventing the Cache-Control Response Header from being Set to private).
If compression is enabled on the NetScaler, two of the default policies (ns_cmp_content_type and ns_adv_cmp_content_type) "compress data when the response contains Content-Type header and contains text" (see http://docs.citrix.com/en-us/netscaler/10-5/ns-optimization-wrapper-10-con/ns-compression-gen-wrapper-con/ns-compression-configactions-tsk.html). Using the NetScaler API Mgr (nsapimgr) you can prevent the Compression feature from adding the Cache-Control response header (nsapimgr -ys cmp_no_cc_hdr=1).
Hello I want to analyze & understand at first place and then optimize the HTTP header responses of my site. What I get when I fetch as Google from webmasters is:
HTTP/1.1 200 OK
Date: Fri, 26 Oct 2012 17:34:36 GMT // The date and time that the message was sent
Server: Apache // A name for the server
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM" // P3P Does an e-commerse store needs this?
ETag: c4241ffd9627342f5f6f8a4af8cc22ed // Identifies a specific version of a resource
Content-Encoding: gzip // The type of encoding used on the data
X-Content-Encoded-By: Joomla! 1.5 // This is obviously generated by Joomla, there wont be any issue if I just remove it, right?
Expires: Mon, 1 Jan 2001 00:00:00 GMT // Gives the date/time after which the response is considered stale: Since the date is set is already expired, this creates any conflicts?
Cache-Control: post-check=0, pre-check=0 // This means site is not cached? or what?
Pragma: no-cache // any idea?
Set-Cookie: 5d962cb89e7c3329f024e48072fcb9fe=9qdp2q2fk3hdddqev02a9vpqt0; path=/ // Why do I need to set cookie for any page?
Last-Modified: Fri, 26 Oct 2012 17:34:37 GMT
X-Powered-By: PleskLin // Can this be removed?
Cache-Control: max-age=0, must-revalidate // There are 2 cache-controls, this needs to be fixed right? which one is preffected? max-age=0, must-revalidate? post-check=0, pre-check=0?
Keep-Alive: timeout=3, max=100 // Whats that?
Connection: Keep-Alive
Transfer-Encoding: chunked // This shouldnt be deflate or gzip ??
Content-Type: text/html
post-check
Defines an interval in seconds after which an entity must be checked for freshness. The check may happen after the user is shown the resource but ensures that on the next roundtrip the cached copy will be up-to-date.
http://www.rdlt.com/cache-control-post-check-pre-check.html
pre-check
Defines an interval in seconds after which an entity must be checked for freshness prior to showing the user the resource.
Pragma: no-cache header field is an HTTP/1.0 header intended for use in requests. It is a means for the browser to tell the server and any intermediate caches that it wants a fresh version of the resource, not for the server to tell the browser not to cache the resource. Some user agents do pay attention to this header in responses, but the HTTP/1.1 RFC specifically warns against relying on this behavior.
Set-Cookie: When the user browses the same website in the future, the data stored in the cookie can be retrieved by the website to notify the website of the user's previous activity.[1] Cookies were designed to be a reliable mechanism for websites to remember the state of the website or activity the user had taken in the past. This can include clicking particular buttons, logging in, or a record of which pages were visited by the user even months or years ago.
X-Powered-By: specifies the technology (e.g. ASP.NET, PHP, JBoss) supporting the web application.This comes under common non-standard response headers and can be removed.
Keep-Alive It is meant to reduce the number of connections for a website. Instead of creating a new connection for each image/css/javascript in a webpage many requests will be made re-using the same connection.
Transfer-Encoding: The form of encoding used to safely transfer the entity to the user. Currently defined methods are: chunked, compress, deflate, gzip, identity.