I am using Fiddler on Google and I noticed that a content type json is arriving as follows:
HTTP/1.1 200 OK
Date: Fri, 02 Dec 2011 22:55:56 GMT
Expires: -1
Cache-Control: no-cache, must-revalidate
Content-Type: application/json; charset=UTF-8
Pragma: no-cache
Content-Disposition: attachment
Content-Encoding: gzip
Server: gws
Content-Length: 317
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
--some big big big big encoded stuff here...--
So the question is: can I use some tool or create some code to unzip this result and see what is inside of --some big big big big encoded stuff here...--?
It seems I can click on the request on the left panel, then choose on Fiddler right bottom panel, click on Transformer tab, uncheck Chunked Transfer-Encoding and click No Compression.
Then click on Raw tab.
Related
I'm trying to use the google drive API using a device_code from the Google API. In the documentation, the Google Drive scope doesn't seem to be listed:
https://developers.google.com/identity/protocols/OAuth2ForDevices#allowedscopes
However, in the exact same page, they have an example that uses the Google Drive API in the https://developers.google.com/identity/protocols/OAuth2ForDevices#callinganapi
When I try connecting using any google Drive scope, with the following request:
POST /o/oauth2/device/code HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: accounts.google.com
Connection: close
User-Agent: Paw/3.1 (Macintosh; OS X/10.12.4) GCDHTTPRequest
Content-Length: 136
client_id=clientid&scope=https://www.googleapis.com/auth/drive.readonly
I get this answer:
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Date: Tue, 23 May 2017 03:02:31 GMT
Server: ESF
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alt-Svc: quic=":443"; ma=2592000; v="37,36,35"
Accept-Ranges: none
Vary: Accept-Encoding
Connection: Close
{
"error" : "invalid_scope"
}
I'm just wandering since there is a difference in the documentation if it is or isn't possible to do it, if I made a mistake or not.
I am trying to inspect an HTTP request made in my browser with the chrome dev tools. I want to see the response but it seems to be empty (failed to load data), whereas the Content-Type is set to 4464326.
Below the HTTP response headers :
HTTP/1.1 200 OK
Last-Modified: Tue, 21 Jan 2014 12:08:30 GMT
ETag: "3ba731138c01f1ad6536bc1d4030cfdd"
Content-Type: audio/mpeg
Server: AmazonS3
Content-Length: 4464326
Accept-Ranges: bytes
Date: Wed, 04 May 2016 13:02:20 GMT
Via: 1.1 varnish
Age: 153069
Connection: keep-alive
Cache-Control: no-cache, no-store, private
X-Served-By: cache-fra1226-FRA
X-Cache: HIT
X-Cache-Hits: 2
X-Timer: S1462366940.863431,VS0,VE0
Plus, in the timeline, I see a download time of 4.61s so I guess to response was not actually empty.
I also tried with Fiddler but responser is still unavailable. Does someone has an explanation, or even better, knows how I can try to read the response ?
As you can see,
Content-Type: audio/mpeg
Can the chrome dev tools read this type of content?
When you are streaming a video, the Response panel shows as empty because the request hasn't completed yet. Once completed, it displays "Failed to load response data", since the data is likely to be too large to display as text in the panel.
You could try Wireshark to capture the HTTP response data.
This one works:
view-source:http://code.jquery.com/jquery-2.0.3.min.js
This one does not:
view-source:http://pagead2.googlesyndication.com/pagead/show_ads.js
The network status is "canceled". Response headers:
HTTP/1.1 200 OK
P3P: policyref="http://www.googleadservices.com/pagead/p3p.xml", CP="NOI DEV PSA PSD IVA IVD OTP OUR OTR IND OTC"
Content-Type: text/javascript; charset=UTF-8
ETag: 18135184975683587730
Date: Thu, 11 Jul 2013 10:00:44 GMT
Expires: Thu, 11 Jul 2013 11:00:44 GMT
X-Content-Type-Options: nosniff
Content-Disposition: attachment
Content-Encoding: gzip
Server: cafe
Content-Length: 6489
X-XSS-Protection: 1; mode=block
Age: 2014
Cache-Control: public, max-age=3600
Without "view-source" I'm able to download the file and view the source but I want to know why this happens.
A strange thing in addition is, that it is not possible to open the web delevoper tools after opening this view-source url. If you do, the tools are completely blank:
I'm taking a guess here: it has to do with the Content-Disposition setting in the Response Header.
Reference: http://support.microsoft.com/kb/260519.
I'm seeing the below response from some calls to a webserver:
Initial call:
HTTP/1.1 200 OK
Date: Mon, 16 Jan 2012 05:46:49 GMT
X-Powered-By: Servlet/2.5 JSP/2.1
Content-Type: text/plain
Content-Length: 78
Content-Encoding: gzip
Etag: "pv2052dae8634d971149a927231e3ceddf"
Cache-Control: no-cache
X-PvInfo: [S10202.C6191.A6057.RA6008.G182D.U3FAE8760].[OT/plaintext.OG/documents]
Vary: Accept-Encoding
Set-Cookie: JSESSIONID=l9pLPT5J1tpgK19Fq2qlT0F15ryByWDLgVLz16ffWPm4qQp6nzzx!-518520380; path=/; HttpOnly
DST=rd319o00000000000000000000ffffac16018bo8200; path=/
Connection: close
Subsequent calls:
HTTP/1.1 304 Not Modified
Date: Mon, 16 Jan 2012 05:48:43 GMT
Connection: close
Etag: "pv2052dae8634d971149a927231e3ceddf"
Cache-Control: no-cache
Vary: Accept-Encoding
What I'm unclear about is that both calls return a Cache-Control: no-cache directive to the browser.
However, the second call also returns a 304 Not Modified.
Where does the server expect the page to serve the data from, given that it's been instructed not to cache the earlier response?
Interestingly, I do see the response served in the browser, so the browser appears to have cached the response, despite the no-cache directive. Why?
A response with Cache-Control: no-cache does not mean that the response must not be stored at the client at all, instead it means:
If the no-cache directive does not specify a field-name, then a
cache MUST NOT use the response to satisfy a subsequent request
without successful revalidation with the origin server. This
allows an origin server to prevent caching even by caches that
have been configured to return stale responses to client requests.
So the client is allowed to store the response in the local cache but it needs to revalidate the response by the origin server. If the server says that the response stored in the client’s cache is still valid (i. e. 304 response), the client is allowed to use the stored response to satisfy the request.
I'm trying to do HEAD requests to follow 302 links, however this link: http://news.google.com/news/url?sa=t&fd=R&usg=AFQjCNGrJk-F7Dmshmtze2yhifxRsv8sRg&url=http://www.mtv.com/news/articles/1647243/20100907/story.jhtml
is troublesome because a HEAD request returns a 200 OK and a GET request returns the expected 302 Status code.
So I'll need to do a GET request but I'd rather not have to pay for the extra bandwidth times that will come from getting the entire HTML document. Anyone know a hack to do a GET without getting the body returned?
UPDATE: took David's advice to do a Range header but they seem to still be ignoring it
GET /news/url?sa=t&fd=R&usg=AFQjCNGrJk-F7Dmshmtze2yhifxRsv8sRg&url=http://www.mtv.com/news/articles/1647243/20100907/story.jhtml HTTP/1.1
Range: bytes=0-10
x-ms-range: 0-600
Host: news.google.com
Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html; charset=UTF-8
Location: http://www.mtv.com/news/articles/1647243/20100907/story.jhtml
Content-Length: 258
Date: Wed, 08 Sep 2010 20:28:16 GMT
Expires: Wed, 08 Sep 2010 20:28:16 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Set-Cookie: PREF=ID=ef5f1bc768645c5e:TM=1283977696:LM=1283977696:S=5n26IrEDpcQTJIb1; expires=Fri, 07-Sep-2012 20:28:16 GMT; path=/; domain=.google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
here.
</BODY></HTML>
File a bug with the web server's owner.
Try using the Range header in your request.
If that doesn't work, can you just hang up the connection after you get the headers you want?
In the specific example you cite, you could just pull it out of the original URL's "url" parameter. But for a more generic approach, I'd stick to David M.'s suggestions