I am tracking an IOS app through fiddler as a proxy. And for some requests from the IOS app, fiddler will display those sessions in a flash and then those sessions are gone. It is against my common sense that why a landed session in fiddler will ever disappear. The only thing I can think of is that the response of the http session is violating the protocol? But the IOS app behaves normally with those http requests and responses.
I did catch some screen shots for the http request while it is being displayed in fiddler, and here is how it looks like for each fiddler column:
#:76
Result:-
Protocol:HTTP
Host:184.102.xxx.xx
URL:/someUrl/someHashCode
Body:-1
Caching:
Does anyone know what is going on here?
In both cases, the traffic is being hidden by a filter. Click Help > Troubleshoot Filters and follow the instructions.
Related
I'm trying to programmatically submit a form on a web site that I do not own. I'm trying to simulate what I would manually do with a web browser. I am issuing an HTTP POST request using an HTTP library.
For a reason that I don't know I am getting a different result (an error, a different response, ...) when I programmatically submit the form compared to a manual submission in a web browser.
How can that be and how can I find out what mistake I have made?
This question is intentionally language and library agnostic. I'm asking for the general procedure for debugging such issues.
All instances of this problem are equivalent. Here is how to resolve all of them:
The web site you are posting to cannot tell different clients apart. It cannot find out whether you are using a web browser or an HTTP library. Therefore, only what you send matters for the decision of the server on how to react.
If you observe different responses from the server this means that you are sending different requests.
A few important things that you probably have to send correctly:
URL
Verb (GET or POST)
Headers: Host, User-Agent, Content-Length
Cookies (the Cookie and Set-Cookie headers)
The request body
Use an HTTP sniffer like Fiddler to capture what you are programmatically sending and what your browser is sending. Compare the requests for differences. Eliminate the differences one by one to see which one caused the problem. You can drag an HTTP request into the Composer Window to be able to modify and reissue it.
It is impossible to still get a different result if you truly have eliminated all differences between the manual and the programmatic requests.
Recently I am doing a research on the request/response model of the facebook mobile app. I am using the fiddler 4 to capture all the http/https conversation from the facebook app on my iphone 4s. What I did was setting my desktop as a proxy and redirecting all the iphone network traffic through it. By the way, I have configured the fiddler so that all the https conversations are also transparent.
One interesting thing I find is that, although I am able to capture all the requests and responses for the graphics and jsons. I never found any request regarding the Comments or Likes, nor can I find any information of the new feed that's in plain text.
My question is, did I miss something or such "plain text" conversations are happening on a different transport layer or with some different protocol?
How am I able to get these conversations in my fiddler?
Thanks
All communication with the server API should be running over HTTPS. It means it's SSL encrypted and you are unable to see the plain text communication on your proxy. That behaviour is on purpose to protect the users data. You surely wouldn't be happy if anybody on a way of packets from your iPhone to the Facebook API's could read your messages for example :-)
You are saying you made "https transparent". I don't know what exactly you mean, but unless you make classical man-in-the-middle attack by faking certificates, you have no chance to see the open text communication of HTTPS. And I think FB has it covered and will detect change of certificates.
Edit: I just have checked it out using Charles proxy and yes, all the communication to the Facebook API is (of course as expected) HTTPS, so you will never see any open text communication.
As you know, you can easily configure Fiddler to decrypt HTTPS traffic.
My first guess is that the "Like" and "Comment" data are transferred over a HTML5 WebSocket. Do you see any WebSockets in the traffic from the application?
I am trying to send Http Requests from Android phone using Apache HttpClient to a server routing my requests via Fiddler. For certain requests, the DefaultHttpClient.execute throws a NoHttpResponseException, but this particular request is not seen in the fiddler at all.
The same thing happens if i direct my traffic without Fiddler but directly over wifi. The code for execute works fine generally.
Fixed this by handling the NoHttpResponseException and re-sending the request. When the same requests gets sent again, it goes through fine.
I would be interested to know the root cause of this issue - but for the time being this works for me.
I'm trying to hook UIWebView so that when a user enters a url, they are re-directed through our proxy and prompted for authentication.
I'm essentially needing to take the request and add proxy information to the request and pass it over to a UIWebView.
The proxy has to be controlled by the iOS application and not by safari or read from system wide credentials.
I've tried using ASIHTTPRequest to create a request to route through a known proxy with NTLM authentication, that works fine however doesn't bring back css, javascript, images etc.
I then read about and used ASIWebPageRequest however that is currently a bit unstable, doesn't stream and waits for the whole HTML site to download before rendering it to the user.
Can anyone point me in the right direction?
Are you allowed to change the content of the pages so that they point directly to your proxy? That might work.
Personally I'm very curious if there is any other way to do this without rewriting URLs (basically w/ only client side changes). If you found a solution please let me know1
Say I have a web page which does a permanent redirect to another page. The status code sent should be 301. I would like to test this (ie to check that the status code is indeed 301) but the browser redirects automatically to the new page and I don't have the time to check the status code returned.
Any ideas?
Fiddler is your friend here, it can monitor all web traffic and you will be able to see the 301 being sent back.
You can download it from http://www.fiddler2.com/fiddler2/
You can check your logs in IIS, it keeps track of requests and the response code it sent back.
You can also use a tool like Fiddler which works with IE and it will show you the request/response data.
Other browsers likely have their own tools that will show you this information also.
I would recommend that you use a web debugging tool that will allow you to look at what requests and responses have been received by the browser. Fiddler is a free, useful tool in seeing these items.