Make sure that filters apply to MS telemetry calls (e.g. v10.vortex-win.data.microsoft.com)
Microsoft telemetry calls to v10.vortex-win.data.microsoft.com bypass the filters and add noise. If my filter says only show localhost, I don't expect to see calls to Microsoft.com.
Exactly the same problem here. These "vortex" violations make fiddler next-to-useless -- or at least, makes Filtering useless, because you still can't focus on the items you're trying to focus on.
I'm setting Protocol Violations to "Do Not Show" -- but at the very least, this option should be present IN the Filters pane, as part of the Filter config, so there's some clue as to how to accomplish what you're actually there to do in the first place.
Guest commented
3 Aug, 2018 01:00pm
This can be done in the fiddler script editor, just dont display sessions where the hostname contains "vortex"
Greg Woods commented
29 May, 2018 11:14am
>or you could possibly write code that masks out the SessionFlags.ProtocolViolationInRequest flag on requests you don't care about.
My point was that fiddler already knows about "requests I don't care about"...these are in the Filters., so it seems logical that fiddler applies filter rules to protocol violations.
For now I have ignored all protocol violations, editing OnPeekAtRequestHeaders resulted in everything being filtered out. Probably something I did wrong, but I haven't time to investigate at the moment.
Guest commented
17 May, 2018 09:17am
Would love to get this fixed. None of the suggestions fix this, or at least need better explanations, I was unable to get onpeekheaders to do fuck all.
Eric Lawrence commented
15 May, 2018 08:29pm
Okay, I spent a few minutes looking at this.
> if I have filters enabled, nothing should bypass those filters... it's just bad manners.
Fiddler's filters deliberately ignore cases where there's good reason to believe that something has broken that might not be failing without Fiddler in the way. Otherwise, running Fiddler could cause side-effects that would be nearly impossible to troubleshoot.
Now, unfortunately, because of how stealth is implemented, it's not applied to cases where there's a protocol violation in the Request or Response. The test in the ShouldBeHidden function probably should be changed to respect stealth because it's a non-default override.
As a user, to make these lines go away, you could either change Tools > Fiddler Options > General > "If protocol violations are observed" to "Do Nothing" (which is sad, because protocol violations ARE generally very useful), or you could possibly write code that masks out the SessionFlags.ProtocolViolationInRequest flag on requests you don't care about. Or you could hack together code that just hides them periodically. (eww).
The script sample earlier has two typos-- the function is named uriContains and the word stealth needs to be in lowercase.
For best results, put it inside OnPeekAtRequestHeaders:
if (oSession.uriContains("watson.telemetry.microsoft.com")) { oSession["ui-hide"] = "stealth-boring boring boring...."; }
Guest commented
15 May, 2018 03:50pm
Same shit for me. I couldn't find a way to solve it yet.
Steven Lamport commented
22 Apr, 2018 04:04pm
I have the same issue and it drives me crazy. I have tried just about everything but these still show.
Greg Woods commented
22 Mar, 2018 03:20pm
An example of the amount of crap filling my fiddler sessions
telemetry.PNG
telemetry.PNG
View full size image
telemetry.PNG
Ed Eaglehouse commented
22 Mar, 2018 02:04pm
20 minutes later, STEALTH isn't working for me, either. The telemetry responses are still showing up.
Ed Eaglehouse commented
22 Mar, 2018 01:00pm
I tried adding the ui-hide member on the session in the OnBeforeResponse handler using Eric's STEALTH suggestion. Fiddler threw a compilation error, "Objects of type 'Fiddler.Session' do not have such a member."
Using automatic syntax completion and comparing other code in CustomRules.js, the urlContains function was apparently renamed uriContains. Fiddler didn't complain after I used the latter function name.
I agree with Greg Woods' comment about filters actually filtering what you tell them to. Perhaps an additional UI option to show/hide protocol violations would be in order.
Greg Woods commented
15 Mar, 2018 10:22am
My sessions list is being filled with Windows 10 telemetry calls, all with 408 errors. Even trying to remove them using fiddler script (a workaround) has failed.
Quote: "(By default, Fiddler doesn't hide sessions which resulted in HTTP Protocol Violation errors)."
IT SHOULD.
if I have filters enabled, nothing should bypass those filters... it's just bad manners.
Gunnar S commented
8 Mar, 2018 04:08pm
The problem identified by James Brooks is driving me nuts. There must be a way to stop this from showing up in Fiddler:
Host: v10.vortex-win.data.microsoft.com
HTTP/1.1 408 Request body incomplete Date: Thu, 08 Mar 2018 16:01:58 GMT
James Brooks commented
21 Feb, 2018 12:53am
Nope, spoke to soon. Adding "Hide if URL contains" did not work. Sorry.
James Brooks commented
21 Feb, 2018 12:41am
As a side note. Under "Filters" --> "Hide if URL contains" --> v10.vortex-win.data.microsoft.com does work in hiding it from Fiddler
James Brooks commented
21 Feb, 2018 12:34am
I am also having issues with https://v10.vortex-win.data.microsoft.com/collect/v1 in Fiddler. My filter is on and set to "Show only the following Hosts" -- "localhost" yet I see both localhost and v10.vortex-win.data.microsoft.com I can right click on it and choose "Filter Now --> Hide v10.vort... yet after a few captures, it starts showing v10 again. Always with 408 request body incomplete.
Eric Lawrence commented
19 Feb, 2018 01:16pm
Regarding the claim that "Stealth" doesn't work-- the most likely explanation is that you either wrote the rule incorrectly, or put it in the wrong place. Feel free to email me a SAZ capture demonstrating your issue. bayden at gmail dotcom.
Rainer Koschnick commented
6 Feb, 2018 09:48am
STEALTH doesn't work for me, those requests still show.
Eric Lawrence commented
29 Jan, 2018 04:41pm
In the Session's Properties, you can see what exactly the protocol violation in the request is; depending on what the problem is, it reflects either a bug in the client (likely) or something that could be fixed in Fiddler.
To cause a Session to be hidden regardless of protocol errors, you can add the word "STEALTH" to the UI-HIDE value, e.g.
if (oSession.urlContains("watson.telemetry.microsoft.com")) { oSession["ui-hide"] = "STEALTH-boring boring boring...."; }
Dave Carlson commented
25 Jan, 2018 08:22pm
By block, I mean hide from the list.
Dave Carlson commented
25 Jan, 2018 08:22pm
My host is slightly different: watson.telemetry.microsoft.com. I tried setting up a "Hide if URL contains" and "hide following hosts", but it still shows up. I also tried adding a line in the custom rules file, but it still powers through.
It is a protocol violation: "ProtocolViolationInRequest".
Is there a special way I can block this specific request?
Exactly the same problem here. These "vortex" violations make fiddler next-to-useless -- or at least, makes Filtering useless, because you still can't focus on the items you're trying to focus on.
I'm setting Protocol Violations to "Do Not Show" -- but at the very least, this option should be present IN the Filters pane, as part of the Filter config, so there's some clue as to how to accomplish what you're actually there to do in the first place.
This can be done in the fiddler script editor, just dont display sessions where the hostname contains "vortex"
>or you could possibly write code that masks out the SessionFlags.ProtocolViolationInRequest flag on requests you don't care about.
My point was that fiddler already knows about "requests I don't care about"...these are in the Filters., so it seems logical that fiddler applies filter rules to protocol violations.
For now I have ignored all protocol violations, editing OnPeekAtRequestHeaders resulted in everything being filtered out. Probably something I did wrong, but I haven't time to investigate at the moment.
Would love to get this fixed. None of the suggestions fix this, or at least need better explanations, I was unable to get onpeekheaders to do fuck all.
Okay, I spent a few minutes looking at this.
> if I have filters enabled, nothing should bypass those filters... it's just bad manners.
Fiddler's filters deliberately ignore cases where there's good reason to believe that something has broken that might not be failing without Fiddler in the way. Otherwise, running Fiddler could cause side-effects that would be nearly impossible to troubleshoot.
Now, unfortunately, because of how stealth is implemented, it's not applied to cases where there's a protocol violation in the Request or Response. The test in the ShouldBeHidden function probably should be changed to respect stealth because it's a non-default override.
As a user, to make these lines go away, you could either change Tools > Fiddler Options > General > "If protocol violations are observed" to "Do Nothing" (which is sad, because protocol violations ARE generally very useful), or you could possibly write code that masks out the SessionFlags.ProtocolViolationInRequest flag on requests you don't care about. Or you could hack together code that just hides them periodically. (eww).
The script sample earlier has two typos-- the function is named uriContains and the word stealth needs to be in lowercase.
For best results, put it inside OnPeekAtRequestHeaders:
Same shit for me. I couldn't find a way to solve it yet.
I have the same issue and it drives me crazy. I have tried just about everything but these still show.
An example of the amount of crap filling my fiddler sessions
20 minutes later, STEALTH isn't working for me, either. The telemetry responses are still showing up.
I tried adding the ui-hide member on the session in the OnBeforeResponse handler using Eric's STEALTH suggestion. Fiddler threw a compilation error, "Objects of type 'Fiddler.Session' do not have such a member."
Using automatic syntax completion and comparing other code in CustomRules.js, the urlContains function was apparently renamed uriContains. Fiddler didn't complain after I used the latter function name.
I agree with Greg Woods' comment about filters actually filtering what you tell them to. Perhaps an additional UI option to show/hide protocol violations would be in order.
My sessions list is being filled with Windows 10 telemetry calls, all with 408 errors. Even trying to remove them using fiddler script (a workaround) has failed.
Quote: "(By default, Fiddler doesn't hide sessions which resulted in HTTP Protocol Violation errors)."
IT SHOULD.
if I have filters enabled, nothing should bypass those filters... it's just bad manners.
The problem identified by James Brooks is driving me nuts. There must be a way to stop this from showing up in Fiddler:
Host: v10.vortex-win.data.microsoft.com
HTTP/1.1 408 Request body incomplete
Date: Thu, 08 Mar 2018 16:01:58 GMT
Nope, spoke to soon. Adding "Hide if URL contains" did not work. Sorry.
As a side note. Under "Filters" --> "Hide if URL contains" --> v10.vortex-win.data.microsoft.com does work in hiding it from Fiddler
I am also having issues with https://v10.vortex-win.data.microsoft.com/collect/v1 in Fiddler. My filter is on and set to "Show only the following Hosts" -- "localhost" yet I see both localhost and v10.vortex-win.data.microsoft.com I can right click on it and choose "Filter Now --> Hide v10.vort... yet after a few captures, it starts showing v10 again. Always with 408 request body incomplete.
Regarding the claim that "Stealth" doesn't work-- the most likely explanation is that you either wrote the rule incorrectly, or put it in the wrong place. Feel free to email me a SAZ capture demonstrating your issue. bayden at gmail dotcom.
STEALTH doesn't work for me, those requests still show.
In the Session's Properties, you can see what exactly the protocol violation in the request is; depending on what the problem is, it reflects either a bug in the client (likely) or something that could be fixed in Fiddler.
To cause a Session to be hidden regardless of protocol errors, you can add the word "STEALTH" to the UI-HIDE value, e.g.
By block, I mean hide from the list.
My host is slightly different: watson.telemetry.microsoft.com. I tried setting up a "Hide if URL contains" and "hide following hosts", but it still shows up. I also tried adding a line in the custom rules file, but it still powers through.
It is a protocol violation: "ProtocolViolationInRequest".
Is there a special way I can block this specific request?