I have 16 GB memory, and why is fiddler drop body (doesn't parse the body) to conserve memory?
how to disable this feature?
This message is shown when loading a har archive. It means that the response body is not in the archive that you opened.
The body was not dropped by Fiddler. It was dropped by the creator of the .har file (eg Chrome).
See here: https://fiddler.ideas.aha.io/ideas/FID-I-40
Related
Attached are three screenshots from Google Chrome Network Tools for the same website.
They are filtered to show images from the Amplience CDN
The results shown in the Size/Content column vary and I am trying to understand why.
Each screenshot is taken from the point of view of a returning user. Therefore the images should come from Cache.
Screenshot 1 - Shows a big difference between Size on Disk and Transfer Size.
Screenshot 2 - Shows that one of the images is now NOT cached
Screenshot 3 - the term (from Cache) is now displayed.
My questions are:
In screenshot 1, why does it not say (from cache)? What is happening in the small amounts of Transfer Size that is not happening in screenshot 3?
Why is it that one image is suddenly not cached?
My responses:
In screenshot 1, why does it not say (from cache)? What is happening in the small amounts of Transfer Size that is not happening
in screenshot 3?
If you had the "Status" displayed, you'd probably see a "304 Not Modified". In this case, the cache was used AND the network was used. A request was sent to the server and the response only contains headers that are 257 bytes long.
Why is it that one image is suddenly not cached?
There can be many reasons so it's hard to answer without more information.
It could be that you asked for a "hard refresh" (Ctrl + Shift + R).
It could be that the response contained a "Age" header that was bigger than the "Cache-Control: max-age=xxx", or a "Date" header that was too far in the past.
I can also think of a case when the browser sends a request with a "If-modified-Since" header or a "Etag" header, and your servers (in your case the CDN servers) do not all respond with the same information.
Browsers sometime remove things from the cache, usually when they need to make space for some other files.
I want to modify the responsebody.
However, the data is compressed by Brotli, which fiddler does not support.
I want to set a response breakpoint.
When fiddler break on the response.
I decompress the data with a tool, modify it and compress the modified data.
Copy the modified data to the fiddlerscript and save the fiddlerscript.
But I find that the response breakpoint breaks after the response arrived.
So when I resave the fiddlerscript, the script won't work on the breaked response.
How can I modify a responsebody compressed with an unsupported algorithm?
You can install the Compressibility add on from http://www.telerik.com/fiddler/add-ons. This adds Brotly support to Fiddler at present.
I'm trying to edit the content of a Request in mitmproxy and pass it over, but the content of the body is encoded by gzip. I can see the structure of data which is like xml, but I cannot edit it and save it in gzip format. How can I resolve this issue? I tried different tutorials, but none of them are going into detail in that level
I was not able to get this to work using mitmproxy 0.11.1, because every time I tried to edit the response, the body would open in my text editor as the raw gzipped source. However, it did work in mitmproxy 0.11.3. Unfortunately, there appear to be no release notes for the 0.11.2 or 0.11.3 releases.
I set up an i ~bs (response body) intercept hook, and a l ~bs filter to display the intercepted message. I loaded the page in a browser, opened the request, pressed tab to view the response body, hit e to edit, and r for raw body. That opened my editor with the body response as unformatted ASCII text, not the raw gzipped encoding. After saving a one-character change and exiting the editor, I hit a to accept and send the updated message, and saw the change in the web browser developer tools.
However, on several other occasions while doing this and changing a lot of characters in the response body, mitmproxy crashed.
I am new to GWT.
I want to load a large text file (50 MB) from GWT client side and output the file content in a textarea.
I tried Requestbuilder and I passed response.getText() to a string. I am able to do this for a 10-12 MB file but then it just hangs. I think it has something to do with some maximum limit of string. I can not pass the output of response.getText() to a file because then I would not be able to read that file from GWT client side as I'd need bufferreader and all.
I don't know how to make server chunk the file and send one by one responses.
Can anybody please help me with it!
Although the best option will be a server servlet to split the file so as the client could show it paginated, another option is to make the browser natively deal with the big data.
Create an iframe whose source is the url of the file in the server. If the server sends the correct headers (text/plain) the browser will show the content correctly.
Frame f = new Frame("path_to_myfile.txt");
f.setSize("600px", "400px");
RootPanel.get().add(f);
I received an email a while ago with an image attachment in it. Since then, it seems hotmail has stopped hosting the image for me as when I open the message, the image is no longer available.
However, the message source is still intact, and if I'm not wrong, the message source - in text form - also contains the image.
The problem is of course it is in text form. The part which (I believe) contains the image looks something like this: (Just the first few lines)
--Apple-Mail-2--733971985
Content-Disposition: inline; filename=photo.JPG Content-Id:
<3F8BDC26-81F3-4BA2-9071-53E78CB3DB63/photo.JPG>
Content-Type: image/jpeg; name=photo.JPG Content-Transfer-Encoding:
base64
/9j/4AAQSkZJRgABAQEASABIAAD/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdC
IFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAA
AADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFj
cHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAA
ABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAAD
TAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJD
It was sent from my iPhone into Hotmail.
Is this text representing the image that I am missing? I don't believe there is a program out there that can convert this for me, so I am willing to write my own program to do it. Question is, is this even possible?
Yes, this is entirely possible, by various methods. If you have the entire message source, you could save it into a file (something like *.eml) and open it in a mail client (e.g. Mozilla Thunderbird); this should show you the entire message including the attached image.
If not, it's still possible: as you can see from the headers, the image is base64-encoded. You need to revert this transformation - either using your own code (e.g. PHP has base64_decode()), or through various base64-decoders available online (e.g. this). The part you want to decode is the block starting with /9j/4AAQSk in this case. Rename the resulting file photo.JPG (as indicated in the e-mail headers) and you're done.
Note that this requires you to verify that you have put the entire base64-encoded file through the decoder - base64 has no marker to detect the end of file.