Omit display of HTTP requests by URL or other means - visual-studio

When using Fiddler for web debugging with Visual Studio, the vast majority of requests appear to be Visual Studio keepalive's which have nothing to do with development of the website.
I just discovered the "Filters" tab which includes: Show only if URL contains:, but I don't see anything like "Do not show if URL contains:"
Below is an image showing the traffic in question.
The contents of which resembles:
GET /67e56dbd9660475b992bdb4884bf024c/arterySignalR/poll?transport=longPolling&connectionToken=AQAAANCMnd8BFdERjHoAwE%2FCl%2BsBAAAAA9mo0FfMdkuV%2FOrook6XLgAAAAACAAAAAAADZgAAwAAAABAAAACdwdngu4Q3YaxNPSSSB6SaAAAAAASAAACgAAAAEAAAAEpHLB83IL2dS4l5v3LvZ4woAAAAPAHEqYMxK%2Fwwk%2Be%2FEq3MMrbOM4ao8Nhip4toaFxOxM0ARXitnQCueRQAAADELXsi%2FlcBeN%2BcFxQKtcMb7Yvd3A%3D%3D&messageId=d-B39A7C95-E4%2C0%7CE7%2C4%7CE8%2C0&requestUrl=http%3A%2F%2Flocalhost%3A56602%2FReticleDatabase%3Fsubmit%3DSearch%26process%3D%26device%3D%26lev_no%3D999%26xadj%3Dtrue%26xadj%3Dfalse%26xmag1%3Dtrue%26xmag1%3Dfalse&browserName=Internet+Explorer&tid=8&callback=jQuery18206701631324945791_1391540298842&_=1391540397878 HTTP/1.1
Accept: application/javascript, */*;q=0.8
Referer: http://localhost:56602/ReticleDatabase?submit=Search&process=&device=&lev_no=999&xadj=true&xadj=false&xmag1=true&xmag1=false
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept-Encoding: gzip, deflate
Host: localhost:61010
Connection: Keep-Alive
How can I filter (not display) this junk data in Fiddler?

Fiddler offers many ways to filter data. The most powerful mechanism is FiddlerScript. Click Rules > Customize Rules. Scroll to OnBeforeRequest and add:
if (oSession.urlContains("SignalR/poll?")) { oSession["ui-hide"] = "FiddlerScript hides signalR"; }
Save the file.
(It's not entirely clear that SignalR's longPolling requests really have "nothing to do with development of the website", but if you don't want to see them, they're easily hidden.)
Incidentally, the next build of Fiddler's Filters tab will include a Hide URLs containing option. Thanks for the suggestion.

Related

Jmeter: 443 failed to respond

I'm a newbie to JMeter so be gentle. I have a simple test plan that hits a login page. At this point, it doesn't even log in, just loads the page. The problem is that on each run, the request for one of the CSS files on the page results in:
org.apache.http.NoHttpResponseException: example.com:443 failed to respond
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:141)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:286)
at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:257)
at org.apache.jmeter.protocol.http.sampler.hc.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:199)
at org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.receiveResponseHeader(MeasuringConnectionManager.java:212)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:684)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:486)
at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:835)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:697)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:455)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$ASyncSample.call(HTTPSamplerBase.java:2034)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$ASyncSample.call(HTTPSamplerBase.java:2002)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
If I run the test again, all other requests succeed, but this one file fails every time.
Here's the request data:
GET https://example.com/mysite/style/bootstrap.min.css
GET data:
Cookie Data:
JSESSIONID=0753E35583DE3C882E88BE4C37FCFB47; BIGipServerdemo-tomcat=654354624.51526.0000
Request Headers:
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Host: example.com
When I load this page in Chrome or Firefox, all files load, including this CSS file, without any problem. How can I fix this NoHttpResponseException so this CSS file (and I'm assuming more down the road) return as expected?
I was having the same issue with both embedded resources and the main HTTP requests.
Disabling the 'Use KeepAlive' option in the HTTP Request Samplers fixed the issue for me.
This file might be in your browser cache, try using clean session and inspect the request using browser developer tools and double check if the file still there. If not - it's an issue with your application deployment. If yes - I can think only of comparing requests sent by JMeter and real browser using either View Results Tree listener and browser developer tools or external sniffer tool like Wireshark
As a workaround you can disable checking missing embedded resources by adding the next line to user.properties file
httpsampler.ignore_failed_embedded_resources=true
JMeter restart will be required to pick the property up.
You should check HTTP_Request's Retrieve All Embedded Resources from HTML Files checkbox
Tell JMeter to parse the HTML file and send HTTP/HTTPS requests for all images, Java applets, JavaScript files, CSSs, etc. referenced in the file
So you don't need to make explicit request for each CSS (As browser)

HTML5 Progressive Streaming -- no follow-up range requests

I'm working on an embedded device that is recording video on the fly. I'd like to stream that to an HTML5 video element, using our own custom server. I have this almost working and would like some help.
So far as I can tell, I've got libav / ffmpeg doing their job right. I encoded an mp4 in RAM with the moov atom at the start of the file. I've written this file to disk and it plays everywhere it should.
The problem, I think, lies with how I'm responding to HTTP range requests. When I try to do a live stream, I get an initial range request from the browser / player (currently tried Chrome, Firefox, and VLC) for bytes:0-. I responded with some initial bytes. The browser / player actually plays this fine, but never asks again. So the live stream doesn't work, just the first 3 seconds or whatever.
I've looked at the RFC spec of partial content, and my understanding is I'm doing what I should be... Clearly I'm not though. Here is an example of a request / response with Chrome as the requester:
get /live.mp4 HTTP/1.1
host: localhost:1235
connection: keep-alive
accept-encoding: identity;q=1, *;q=0
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36
accept: */*
dnt: 1
accept-language: en-GB,en-US;q=0.9,en;q=0.8
range: bytes=0-
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: video/mp4
Content-Length: 182400
Content-Range: bytes 0-182399/*
Again, with that request / response pair, Chrome plays the first 182400 bytes but never makes a second request. I thought having the '*' in Content-Range would make this happen...
Progressive download doesn’t work that way. It browser assumes the file will never change. To play a live stream you need to use fragmented MP4 and media source extensions.
This was the problem. I needed media extensions, it wasn't clear to me that progressive streaming wasn't for live feeds of unknown length. Media extensions and a websocket solved the issue. Also needed to use -dash for libav to make it work in Chrome.
I came across a similar issue where it was working perfectly on Firebox but only plays the first fragment of the video in Chrome and does not request any other. My case was solved simply by making the very first response return nothing with a 200 status code and Accept-Ranges: bytes header.
Looks like it is common, check the update part for the following question: Content-Range working in Safari but not in Chrome

Unable to recieve PUT Data using Code Igniter, REST, Lighttpd url-rewrite and Backbone.js

I am using CodeIgniter with REST APIs and Backbone.js. Web server is lighttpd. I also have lighttpd.conf changed for rewriting URLs to remove index.php from urls as follows:-
url.rewrite-once = (
"/(.*)\.(.*)" => "$0",
"/(css|files|img|js|stats)/" => "$0",
"^/([^.]+)$" => "/index.php/$1"
)
The call from js reaches to Codeigniter Put function but the value for $this->put() is empty. Please help me out in tracing why the value for PUT data is empty.
Note: This works perfectly fine when I don't rewrite the URLs. Also this works for Apache web server.
On debugging REST_Controller.php file, in the function "protected function _parse_put()", I found out that the contents of file "php://input" is also empty
Following is the Request Headers and Payload taken from Chrome Web inspector, while making a PUT Call:-
**Request Headers**
PUT http://10.82.0.160/cav_settings/api/2 HTTP/1.1
Pragma: no-cache
Origin: http://10.82.0.160
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17
Content-Type: application/json
Accept: application/json, text/javascript, */*; q=0.01
Referer: http://10.82.0.160/settings/2
X-Requested-With: XMLHttpRequest
**Request Payload**
{"aggregation":{"enabled":"false","mode":""},"dns":{"auto":"false","servers":["10.0.0.5","10.20.0.20"]},"id":"2","dhcp":"false","ip":"10.82.0.160","netmask":"255.255.255.0","default_gw":"","mtu":"1500"}
you can use Backbone.emulateJSON = true;
This is the best answer for your doubt :)
Backbone.js PUT/DELETE problems with Codeigniter REST server

403 Forbidden error in Firefox only, works in Chrome and Safari

I have a Firefox quicksearch bookmark that runs a Maxmind query. This worked until recently. I type 'ip 82.176.230.15' (for example) into the URL bar and it queries Maxmind to retrieve the location of the IP:
http://www.maxmind.com/app/locate_demo_ip?ips=82.176.230.15
Within the past week, for reasons unknown, I now get a 403/Forbidden error when I try to access Maxmind.
"You don't have permission to access /app/locate_demo_ip on this server"
Strangely, the same URL is accessible in Chrome and Safari. I can also access the same URL with Firefox, Chrome, or Safari on my Mac.
I've deleted all cookies, disabled all addons, and still can't get it to work. Any idea what could be happening? I know that the 403 has to come from the server, so I don't know why it would work in other browsers. And it's been going on for days, definitely not some glitch on their server.
Get an HTTP debugger like firebug or fiddler (not sure that will work with FireFox, but probably if you set it up right)
Look at the difference between using your quick bookmark and just typing the URL. The server could return 403 whenever it feels like -- see if there's any difference, and what it is.
I recently had the same issue and was able to fix it.
In my case the problem was in headers that Mozilla sent.
Particularly it was because of header:
"User-Agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0"
What makes web-site refuse connection is this part of string "(X11; Ubuntu; Linux x86_64; rv:100.0)" and i have no idea why.
I found a nice solution, you can change Mozilla settings to include other browsers in this header (Chrome and Safari) and it could make sites with this problem works.
Here is how to do it:
Type about:config into the URL bar. Press Enter.
Create a new entry with key=general.useragent.override and add this string there Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.115 Safari/537.36. I found that Google Chrome uses this string as User-Agent header probably to prevent such issues. So you should see something like:
Now save this settings and go reload your page, it should work now

Why does ie8's user agent return 'opera'?

My code at: http://www.mgxvideo.com/mgxcopy-dev/get_browser.php, returns Opera when I run IE8. My source is:
<?php
$browser = get_browser(null, true);
echo $browser['browser'];
?>
It doesn't. The get_browser() function is making educated (but ill-informed) guesses about which browser the user-agent is running. Your browser capabilities file is likely outdated, probably because it was made before IE8 was released. Update it here.
The real IE8 user-agent string looks something like this:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)
You should use a lower-level tool, like a packet trace or server logging or a header dump to see what is being sent.

Resources