I suspect that I can still debug Web service applications without using Fiddler Everywhere … but I wouldn’t want to have to find out. Fiddler Everywhere continues to see improvements in both functionality and ease-of-use. The current version, for example, includes support for gRPC services, including both “native” gRPC mode over HTTP/2 and “transcoded” mode over HTTP/1.
I’ve looked at creating a gRPC service with transcoding support using Visual Studio with .NET Core elsewhere. This post is about how you can use Fiddler Everywhere when calling a gRPC service from a .NET Core client over HTTP/1 and HTTP/2.
HTTP/2 support for using Fiddler Everywhere with gRPC is automatically enabled for all users. If you want to check this, first start Fiddler Everywhere (from here on, I’ll just call it “Fiddler”). After starting Fiddler, click on the Settings icon in the upper right corner of the Fiddler window and, when the Settings dialog appears, click on the Connections tab on the left and make sure the Enable HTTP/2 Support option is checked.
By the way: If this is the first time you’ve started Fiddler, stop and take a moment to a) look Fiddler’s UI showing all the traffic entering and leaving your computer and b) be amazed by the sheer amount of traffic that’s entering and leaving your computer.
Now you’re ready to write your code to work with Fiddler and with gRPC transcoding on HTTP/1. You’ll need to adjust your default gRPC HTTP/2 code to work with Fiddler and your default RESTful HTTP/1 code to work with a transcoded gRPC service.
If you’re not using Fiddler Everywhere, you would typically use code like the following to create a GrpcChannel object. After creating your channel object, you then pass that channel object to your gRPC client as part of creating the client (the client class’s code will have been generated for you from your gRPC’s service .proto file). That code would normally look something like this:
GrpcChannel gChan = GrpcChannel.ForAddress("https://<URL for gRPC Service>")
GreeterClient gc = new MyGrpcClient(gChan);
Once Fiddler starts, it sets up a proxy that all your network traffic will go through and then reports on that traffic. You’ll need to tweak your gRPC code to play nicely with Fiddler’s proxy which just means adding the extra code shown here to set some GrpcChannelOptions when creating your channel object:
GrpcChannel gChan = GrpcChannel.ForAddress("https://<URL for gRPC Service>",
new GrpcChannelOptions
{
HttpHandler = new HttpClientHandler()
});
GreeterClient gc = new MyGrpcClient(gChan);
With your gRPC code now compatible with Fiddler, you can tweak your RESTful code to work with a gRPC service in transcode HTTP/1 mode. In the past, when calling a RESTful/HTTP 1 service you’ve probably written code like this in .NET Core. This code uses the standard .NET HttpClient object to retrieve an HttpResponseMessage from a RESTful, HTTP/1 service:
HttpClient hc = new HttpClient();
HttpResponseMessage hrpm = await hc.GetAsync("http://<URL> for RESTful HTTP 1 Service>");
While that code is great for a native HTTP 1 service, you need slightly different code to work with a gRPC service that’s using JSON transcoding to make itself available over HTTP/1. To have your .NET Core work with your transcoded gRPC service, you’ll need to add some code when creating your HttpClient object to specify the version of the request message sent to the service by your HttpClient object. That code looks like this:
HttpClient hc = new HttpClient() {
DefaultRequestVersion = new Version(2, 0)
};
HttpResponseMessage hrpm = await hc.GetAsync("https://<URL> for gRPC Service");
With those three changes, you’ll be positioned to have your .NET Core project to work both with Fiddler Everywhere and with a gRPC service in all of its manifestations.
]]>Debugging web applications is essential for identifying and solving problems, either in the code or in some external mechanism. When debugging an application, the developer can follow step-by-step the execution of the code, analyze variables, inspect stacks of calls, and identify possible errors and unexpected behavior, ensuring the quality and proper functioning of the application.
Visual Studio is the main tool for developing .NET applications and offers a wide range of features for debugging in ASP.NET Core, making the process more efficient and productive.
In this blog post, we’re going to create an application in ASP.NET Core and see what are the main functions available in Visual Studio for debugging and troubleshooting.
Visual Studio is a powerful and widely used integrated development environment (IDE) developed and maintained by Microsoft. It offers a comprehensive set of tools and features to make creating, debugging and managing software projects easier.
In the context of ASP.NET Core, Visual Studio has a range of significant functionality for developing and debugging modern, scalable web applications.
Visual Studio’s built-in debugger is an essential tool for finding and fixing errors in ASP.NET Core apps. Through an intuitive interface, the integrated debugger allows developers to examine variables, follow the execution flow and identify complex problems in the code.
To create the application you need to have Visual Studio and the latest version of .NET. This post uses .NET 7, but .NET 8 is available now!
The debugger functions discussed in the post are only present in Visual Studio for Windows.
The source code of the application used in the example can be accessed here: TaskManager.
To create the application in Visual Studio, follow the steps below:
Now let’s create a record that will represent the application’s entity, which in this case will be Tasks. Create a new folder inside the project called “Models” and inside that create a new class called “TaskItem” and replace the existing code with the code below:
namespace TaskManager.Models;
public record TaskItem(Guid Id, string Name, string Description, DateTime CreationDate, DateTime DueDate);
Now let’s create a service class to return some data. As the focus of the post is on debugging the application, we won’t use a database. Instead, the data will be mocked in the service class. In the root of the project, create a new folder called “Services” and in it create a new class called “TaskService.cs” and put the following code in it:
using TaskManager.Models;
namespace TaskManager.Services;
public class TaskService
{
public List<TaskItem> FindTasks()
{
var taskList = new List<TaskItem>()
{
new TaskItem(
Id: Guid.NewGuid(),
Name: "Study ASP.NET Core",
Description: "Study ASP.NET Core for 2 hours a day",
CreationDate: DateTime.Now,
DueDate: DateTime.Now + TimeSpan.FromDays(7)
),
new TaskItem(
Id: Guid.NewGuid(),
Name: "Study ASP.NET Core",
Description: "Clean the room at 4 pm",
CreationDate: DateTime.Now,
DueDate: DateTime.Now + TimeSpan.FromDays(7)
),
new TaskItem(
Id: Guid.NewGuid(),
Name: "Submit Monthly Report",
Description: "Submit the monthly sales report by the end of the week",
CreationDate: DateTime.Now,
DueDate: DateTime.Now + TimeSpan.FromDays(5)
),
new TaskItem(
Id: Guid.NewGuid(),
Name: "Prepare Presentation",
Description: "Prepare a presentation for the upcoming client meeting",
CreationDate: DateTime.Now,
DueDate: DateTime.Now + TimeSpan.FromDays(3)
),
new TaskItem(
Id: Guid.NewGuid(),
Name: "Buy Groceries",
Description: "Buy groceries for the week",
CreationDate: DateTime.Now,
DueDate: DateTime.Now + TimeSpan.FromDays(2)
)
};
return taskList;
}
public TaskItem FindTaskByName(string name)
{
try
{
var taskList = FindTasks();
var task = taskList.SingleOrDefault(t => t.Name == name);
return task;
}
catch (Exception ex)
{
return null;
}
}
}
Note that in the code above we are defining two methods, one to return the complete list of tasks and the other returning a single task based on the given name. The next step is to add the endpoints that will access this data, so replace the Program.cs file with the code below:
using TaskManager.Services;
var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
builder.Services.AddScoped<TaskService>();
var app = builder.Build();
// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}
app.UseHttpsRedirection();
app.MapGet("/tasks", (TaskService service) =>
{
var tasks = service.FindTasks();
return Results.Ok(tasks);
})
.WithName("FindTasks")
.WithOpenApi();
app.MapGet("/tasks/{name}", (TaskService service, string name) =>
{
var task = service.FindTaskByName(name);
return task is null ? Results.NotFound() : Results.Ok(task);
})
.WithName("FindTaskByName")
.WithOpenApi();
app.Run();
Now, make sure that in the “Solution Configurations” tab “Debug” is selected. Run the project by clicking on the start icon in Visual Studio:
Then, in your browser, access the address https://localhost:[PORT]/swagger/index.html
and execute the second endpoint, passing the following in the “name” parameter: Study ASP.NET Core
, as shown in the image below.
Note that the result will be an HTTP status 404, this means that there was an error fetching the data. To find out what the error was, let’s debug the application.
To find the error, let’s follow the steps of executing the application. For that, let’s set a breakpoint where the exception occurs. Then, in the “TaskService.cs” class, in the line where the exception occurs, click in the corner of the Visual Studio tab to set the breakpoint, as shown in the image below:
Breakpoints are a debugging feature. You can set breakpoints where you want Visual Studio to pause your running code—that way you can observe variable values or unexpected behavior.
Now rerun the swagger endpoint passing the Study ASP.NET Core
parameter. Then open Visual Studio and see that the execution was stopped at the breakpoint, and if you click on the “ex” variables and expand it you will be able to
see its value, which in this case is the error we are looking for:
Note that the exception is saying the following: “Sequence contains more than one matching element.” This means that we are filtering a single item through the “SingleOrDefault()” method in the task list, but more than one was found. This happened because the first two tasks have the same name. To solve the problem just change the name of one of the two.
Then stop the debugger and change the name of the second task with the text “Clean the room,” then add another breakpoint where the variable “task” is returned as shown in the image below:
Then run the debugger and the endpoint in Swagger again. Notice that the debugger paused on the breakpoint before the exception. Now if you hover the mouse cursor over the task variable, you will see that the record with the name “Study ASP.NET Core” was successfully found and will be returned on the endpoint.
Visual Studio’s debugger lets you navigate between breakpoints and through lines of code through an intuitive interface. To test these functions, add the following method above the second endpoint code in the Program.cs file:
static bool ValidateTaskName(string name)
{
var userValid = true;
if (name.Length < 3)
userValid = false;
return userValid;
}
And in the second endpoint add the call to the validation method:
if (!ValidateTaskName(name))
return Results.BadRequest("The name must have at least 3 characters");
Then add a breakpoint on the “ValidateTaskName()” method call inside the second endpoint, and then start the debugger again, then in the Swagger interface, on the second endpoint, add the text st
in the name field and click
run:
In Visual Studio, click on the icon that represents a down arrow. This will make the debugger’s cursor enter the “ValidateTaskManager()” method:
Then click on the icon with a curved arrow facing to the right. This will make the debugger’s cursor move to the next line. That’s how we navigate through the code through the debugger:
To finish the execution, click on the start icon that has the name “continue.” This function is used to jump straight to the next breakpoint. As we don’t have any more settings, the debugger will execute the rest of the code all at once.
Through the Visual Studio debugger, it is possible to skip code snippets during debugging. Just position the mouse cursor over the debugger cursor and drag it to the desired area. This way it is possible to ignore validation methods, for example, without the need to comment or delete them. The GIF below demonstrates how to do this:
The debugger has functions for inspecting variable values through the Autos and Locals windows. The Autos window shows the variables used in the current line the debugger cursor is on and also in the previous line. The Locals window shows variables defined in the local scope, which is usually the current method or function.
Run the debugger, resubmit the text “Study ASP.NET Core” on the second endpoint, and look in Visual Studio at the Autos and Locals windows.
To access them, in Visual Studio select “Debug>Windows>Autos” from the menu bar for the Autos window and “Debug>Windows>Locals” for the Locals window. The images below show the windows during debugging.
You can track a variable or expression while debugging by adding it to the Watch window.
To verify this function, add this code snippet:
name = name.ToUpper();
to the first line inside the second endpoint, then, with the debugger running, right-click on the variable name and choose Add Watch.
The Watch window will appear by default at the bottom of the code editor, so step through the code to see the value of the name variable change after going through the added code snippet, as shown in the screenshots below:
Another important feature of the Visual Studio debugger is the call stack window, which allows a better understanding of the application’s execution flow, showing the order in which methods and functions are being called.
To check the call stack window, start the debugger and open the call stack window from the Visual Studio menu: Debug>Windows>Call Stack. Step through the code through the endpoints. The method calls plus other details like the line where the code is will be displayed in the call stack window as in the image below.
Visual Studio provides several shortcut keys to help you navigate and control the debugger efficiently. Below are some commonly used debugger shortcut keys:
These shortcut keys may vary depending on the version of Visual Studio you are using and any customizations you may have made. You can also view and customize shortcut keys by going to Tools > Options > Environment > Keyboard
in the Visual Studio menu.
Visual Studio is a formidable tool for developing and debugging ASP.NET Core applications. Through the Visual Studio debugger, it is possible to find bugs quickly by inspecting values of variables and other objects, following the process execution flow with the Call Stack window, in addition to several other resources.
In this post, we saw some of the main functions of the Visual Studio debugger and how to use them, so whenever you need to analyze a problem during development, consider using the advanced features of the debugger and increase your productivity even more.
]]>All Progress Telerik Fiddler Everywhere plans will switch to new prices starting January 15, 2024. Here is what the prices will look like:
Since the launch of Fiddler Everywhere, we have transformed the product in multiple ways and have introduced impactful new features based on industry trends and your continuous feedback. In addition to that, we have always put major focus on security and delivering quality support, so you could have a well-rounded experience with the product that meets your needs along your debugging process.
To continue doing this and providing a feature-rich tool with the latest technologies used, we are adjusting our pricing for Fiddler Everywhere.
As the pricing changes will take effect on January 15, 2024, you have enough time to lock in the current prices.
Any subscriptions you make from now until January 14 for either of the product plans will be charged at the current price visible on our pricing page. Should you decide to make a purchase now, your subscription will continue to be renewed at the current price, unless you make a cancellation and it expires.
Any new subscriptions after January 15, 2024, will use the new prices.
Get your Fiddler Everywhere subscription here.
As you know, the Fiddler Everywhere plan subscriptions renew automatically on a monthly or annual basis. If you are currently subscribed to one of the plans, and the plan remains active, you will be charged at the current, good old price. If you cancel your subscription and it expires after January 15, you will be able to purchase again at the new price only.
If you currently have a canceled Fiddler Everywhere subscription that has not yet expired, you can resume it if you wish to lock in the current price.
Manage your subscription here.
If you want to make any plan upgrades, you can do so at the current prices until January 14, 2024. This way, you will be able to lock in the old price. Any new plan changes and upgrades after January 15 will use the new prices.
If you want to purchase additional seats to your current active subscription, those will be charged again at the current price even after January 15.
You can make upgrades or add more seats from here.
After January 15, the old plans will be marked in Your Licenses page with a “Legacy” label. You will see this label even if your Fiddler Everywhere plan is active. No need to worry—your plan will remain active and renew at the old price unless you decide to cancel it.
If you have owned a Fiddler Everywhere subscription that is now expired, you will see the legacy plan in your Telerik account page with disabled Renew button. The button has a disabled status because you are no longer able to renew this plan at the old price and you will have to make a new purchase from the pricing page. You will still be able to access all saved and shared content you have in the Fiddler Everywhere application.
New Fiddler Everywhere prices will take effect from January 15, 2024. Those will reflect our promise to continue delivering product improvements, optimizations, as well as quality support and features that will help you in your debugging endeavors.
We are announcing these changes some time in advance for 100% transparency and to give you the opportunity to lock in old prices. You will be able to benefit from the current prices if you make any new purchases or plans changes from now until January 14. Make sure your subscriptions stay active after this date to continue renewing at the current prices!
]]>Have you ever needed to capture and debug traffic with limited or no internet on your machine? Or you just wanted to open the application and analyze any previously saved sessions while you’re offline? Offline support in Fiddler Everywhere now solves these use cases. Continue reading to learn more about the feature.
Offline mode in Progress Telerik Fiddler Everywhere allows you to use the application’s core functionalities while working with limited or no internet access. This means that you can start the application, configure the type of capturing that you want to use, generate traffic and analyze it. All options that can help you in your traffic debugging process are also available in the offline mode, such as all Inspectors, Filters, Rules and the Compare Sessions tab. In addition, you can also use the Composer functionality and execute requests without any interruption.
What you can’t do while you are in offline mode is any operations that need access to our cloud services such as saving and sharing resources, both Sessions and Collections.
This feature is beneficial for any users who operate in a company with a stricter environment with limited access to internet. In this case, users would not have access to our login endpoints or backend endpoints. This would require another mechanism for the user to “log in” to Fiddler Everywhere which happens through an offline license file generated for you by our team, which ensures access to the product without online login required.
Once you have the license file, the app will detect and validate it, and you will be good to go and use Fiddler Everywhere in an offline mode.
Currently, the offline mode is supported for the following cases:
Offline support also comes as a part of our Enterprise plan, and we will make sure you are all set up and the integration is successful before you proceed with a purchase.
If you have the license file generated for you, Fiddler Everywhere will read it by default first and let you in the application in an offline mode. You can use the app without any interruption unless you decide you want to share something or save it in the cloud. You will be prompted to sign in online in order to complete the operation.
The next time you open Fiddler Everywhere, offline mode will be enabled if your license file is valid.
To sum up, the offline support in Fiddler Everywhere allows you to use the application without interruption in the following cases:
If one of those applies to you, we have a solution! Reach out to us at telerik-sales@progress.com so we can learn more about your use case and onboard you successfully.
]]>You probably often hear Progress Telerik Fiddler referred to as the “Original Web Debugging Proxy,” and did you know Fiddler is celebrating its 20-year anniversary?
If this makes you feel old, we are with you. However, Fiddler hasn’t skipped a beat in all these years and has continually evolved to become an integral part of the developers’ toolbox worldwide. Today, we ask you to join us in celebrating Fiddler’s 20th anniversary!
Back in 2003, Eric Lawrence started Fiddler with the idea of simplifying the process of debugging web applications.
In the beginning of the 2000s, there was no easy way to debug applications, uncover issues and network errors, or even monitor incoming and outgoing traffic in real time. Checking what’s under the hood was a time-consuming task.
Like all newcomers, the browser developer tools started out as basic solutions specific to one browser, which resulted in having a learning curve for the different types of information and tools they provided.
This lack of standardization led to the need for a more advanced and unified solution that would incorporate debugging methods no matter the browser or setup you might be using in your work process.
Thanks to Eric, Fiddler (now called Fiddler Classic) was born, which was one of the few web-debugging proxies on the market that gave way to an improved web debugging experience. Fiddler would save teams both time and guesswork and leave more resources for the software development itself.
In the following years, Fiddler became the go-to tool that allowed inspection and modification of traffic through innovative functionalities such as AutoResponder rules, FiddlerScript, breakpoints and many more.
Fiddler continued to develop in the years ahead and, eventually, would turn from just one tool into a family of five tools, each aiming to help developers, QAs and support engineers deliver high quality applications and services.
Teams discovered the need for a debugging tool that works on the other operating systems in addition to Windows. That’s when the Mono version was created, which was the first version of Fiddler Classic for macOS and Linux. With the rise of developers operating on macOS and due to performance and stability issues with the Mono port, Progress decided to invest efforts into a new single solution for all operating systems.
In 2018, a beta version of Fiddler Everywhere was born, and, in 2020, the first official version was released which was cross-platform and included premium features.
Fiddler could be associated with a family of multiple products split into three categories:
Fiddler Classic is one of the first network debugging proxies that introduced a standardized platform to monitor and debug traffic on Windows, and it is also the original tool that put the beginning of the Fiddler brand. Fiddler Everywhere is its continuation that works on Windows, macOS and Linux, and aims to solve the software debugging challenges of today with extended functionalities and modernized UI.
Fiddler works as a man-in-the-middle proxy that generates a unique certificate authority (CA) per machine. It stands between your application and the internet and helps exchange data sent by the client and received by the server. Upon installing and trusting the Fiddler CA, Fiddler can decode the otherwise encoded HTTPS traffic.
As an intermediate proxy, Fiddler allows you to track incoming and outgoing traffic from any application or device. The detailed information inside helps you deep-dive into what is being sent back and forth to easily debug your applications and avoid potential vulnerabilities or performance issues being released to end users.
Fiddler is recognized by users as an integral part of the software debugging process and its impact still remains significant 20 years later. We are grateful for the continuous support from the Fiddler community, and we encourage you to keep on sharing your feature requests, ideas and challenges, so we can shape together the future of Fiddler!
If you missed our celebratory, all-star live session don’t worry, we’ve got you covered!
Check out the recording here:
With the upcoming Progress Telerik Fiddler Everywhere 5.0 release, the application will no longer be supported on the following Windows versions:
The change is scheduled for late October 2023. After that, you will no longer be able to start the Fiddler Everywhere application if you are operating on one of those Windows versions.
We are introducing this change because we want to use the latest frameworks and technology within Fiddler Everywhere, which require a higher Windows version to function. The up-to-date technologies will ensure a higher security of the application, which means higher security for our Fiddler users.
The usage of latest technologies will also give us access to new functionalities, and this will result in faster release iterations on our side, as well as easier development of features in the app.
In addition, we are following the same practices as Microsoft which ended the extended security updates for these versions in the beginning of 2023. These versions are officially not supported by Microsoft, and it only made sense for us to follow suit and aim for technology and security excellence.
To be able to start Fiddler Everywhere and continue using the application after this date, you need to upgrade your version to Windows 10 or higher. Keep in mind that the application will not start on a device with Windows 7, 8 or 8.1.
The Fiddler Everywhere version updates are automatic and older version of the application will not be supported, and you will not be able install a previous version of the app on your device. Get the latest Fiddler Everywhere from our download page.
]]>The first thing to notice is the updated Fiddler Everywhere layout that aims to provide smoother onboarding and workflow with the tool. With the 4.4 version, we are also ready to announce that HTTP/2 is out of beta and we fully support this HTTP version. You will also find some Composer improvements—the first of many more to come!
If you have used Fiddler Everywhere, you know that two of the core functionalities in the app are to be able to capture network traffic—with options to analyze, modify and save it for further investigation—as well as to compose API requests with the option to save them as collections.
Those two main features are now split in Fiddler Everywhere, easily visible in the left panel of the app. The first icon will lead you to the Home section that gives some details about your account and license, as well as useful information about the main functionalities in Fiddler Everywhere.
The next section on the left is called Traffic, and you will find there the newly captured traffic, with the different options for capturing, as well as all tools for filtering, inspection and modification of requests. In addition, any saved or shared sessions will also be visible in the left part of the Traffic section. Click on any of the sessions from the tree to open it in a new tab and analyze it.
Separately from the Traffic section is the Composer, accessible from the third icon on the left. In this section, you can create and edit API requests, as well as save them in collections to the panel on the left. We introduced a new “+” button in the Composer pane that makes creating new requests easier and more visible.
Fiddler Everywhere will remember the last open section before closing the app and will land you there the next time you start the tool.
Fiddler Everywhere now offers a more comprehensive journey to onboard and use the application in the most effective way. The Home tab includes useful information about the functionalities of the app divided into three sections:
Capture and Inspect Traffic – You can clearly see the difference between each approach for capturing traffic, as well as quick steps on how to start using the preferred option.
In case you choose to use the System Proxy capturing, you will notice this is now controlled through a new switch located next to the Filters in the second-row tab. This shows in a clearer way the behavior of the switch which turns on and off Fiddler as a system proxy.
The app will remember if you left the system proxy ON or OFF, and will keep the same behavior the next time you open the app.
Modify and Filter Traffic – This section includes brief information on how to use and benefit most from our Rules and Filters.
Compose API Requests – This section gives you quick access and details about our Composer feature.
Read through the options presented in the Home page and open the wizards to walk you through the most important details about each one. Stay tuned for more info coming up here, including easing the process for connecting to Remote and Mobile devices as well!
We took the time to test HTTP/2 in multiple scenarios and ensure we cover all potential performance issues it may cause, or that it did not handle until now. The feature is now revamped to officially support HTTP/2 multiplexing and we will consider making it the default option in one of our next releases.
For now, make sure that HTTP/2 support is enabled from Settings -> Connections.
The latest release also comes with some enhancements related to the Composer:
Be sure to check out the latest Fiddler Everywhere 4.4 version and all new features that come with it. Open the application to start the automatic update or get the latest version from our Fiddler Everywhere download page. We appreciate all your feedback, so keep sharing your thoughts in our Fiddler Everywhere Forum or through the in-product feedback form.
Happy debugging!
]]>Nowadays, Fiddler Everywhere from Progress Telerik is far from being just another proxy tool. The latest application version provides a comprehensive mechanism for inspecting traffic, extracting data, mocking abilities, organizing collections, sharing and more. Fiddler Everywhere can help multiple personas and fit different cases:
The discussed cases above barely scratch the surface! An ocean of possibilities of what you can do and achieve with Fiddler Everywhere awaits you. Below we will cover some practical examples of using and combining the tool’s features to your advantage during everyday work.
Fiddler Everywhere capabilities expanded way above capturing HTTP(S) traffic. The list below quickly describes the core functionalities and how they fit into the day-to-day work with web applications.
One of the common scenarios for Fiddler Everywhere usage combines capturing traffic and modifying the requests/responses on the fly so that you can test different cases and reproduce various issues.
For the demo’s sake, we assume your site’s client is behind a corporate network with strict restrictions. It could be a security tool that restricts access to several domains, including the ability to open a specific CDN. Or it might be a network connection issue, resulting in the request to the CDN to drop or to be extremely slow. You know your site uses the CDN to render the site UI, so you wonder how your page will look in similar conditions. Let’s use Fiddler Everywhere to mock the behavior.
Scrolling further reveals sessions fetching resources from CloudFront CDN (an Amazon content distribution service).
For demonstration purposes, we chose an action with predefined response 502. However, you can use non-graceful close, delay (in milliseconds), custom response, etc. The Rules Builder is potent and comes with various conditions and actions.
The newly created rule is automatically placed at the bottom of your list of rules. If you have multiple active rules, you need to explicitly order them to promote the non-blocking rules and demote them with blocking consequences (all rules that depend on the response are blocking).
The above test demonstrates how quickly—within a few minutes—with the help of Fiddler Everywhere traffic capturing and rules, we can test various scenarios, reverse engineer a site logic and structure, or inspect different aspects and functionalities. Once an issue or a pattern is determined, we can save the sessions and use them for further investigation or share them with collaborators.
Interested in learning more? Check out the following YouTube videos for more practical examples and demonstrations:
Technically, Fiddler Everywhere allows you to capture HTTP/HTTPS traffic, make modifications, mock server behavior, compose requests and much more.
All these features generate a lot of HTTP session data initially available only in its raw form through the Fiddler’s Request and Response inspectors. The community requested a more elaborate and structured way to access some of the data, and the
Fiddler team delivered! We will talk about the exciting tab called Overview.
Let’s assume that our page loads unexpectedly slowly for some reason, and we want to investigate what’s causing the issue. Our demonstration
uses the Fiddler Everywhere documentation landing page, as in the example in the previous section. To simulate the unexpected slow loading of resources, we will create a rule that mocks unexpected behavior by the CloudFront CDN (similar to the previous
example).
The Open Browser option uses a dedicated browser instance that goes through the Fiddler proxy. This is very convenient for testing a specific site without capturing all the system traffic (it can accumulate quickly and pollute your Live Traffic grid). Opening a dedicated browser instance will also spare you the need to clear the cache from your browser explicitly.
As a result, the login page will load with unwanted delay. In a real-life scenario, we can track which request/response has a longer duration (through the Duration column in the Live Traffic grid of captured sessions) and then observe the Overview for clues.
The screenshot below depicts how we can extract information from the Overview tab. Our rule delayed the CDN loading by 5000 milliseconds. We can examine the Times values in the Overview tab and specifically in Statistics > Request Details. The investigation shows the delay between the Client Connected and Server Connected events.
Voila—the reason for the delay is the MITM proxy (expected as we delayed the request on purpose through our own rule). In real life, this is the place to observe if a request or response causes the delay and if the client application, the server or a third party causes the delay.
Fiddler Everywhere is a modern multifunctional tool that upgrades a MITM proxy to a Swiss army кnife network application. Whether you will use it to debug an issue, optimize your applications and servers, inspect traffic for irregularities or exploit a hack, it is the tool that keeps on giving.
The Fiddler Everywhere team has an aggressive release policy that aims to bring more new exciting features constantly— functionalities like GDPR support, environment variables, new advanced Rules options, and many more are just around the corner. Welcome to the brave new Fiddler world!
Learn more about Fiddler Everywhere, and try it for free!
]]>You’re already familiar with Fiddler Everywhere from Progress Telerik and its powerful proxying capabilities. By capturing HTTP(S) traffic, the application enables you to delve into the data with sophisticated inspection and manipulation tools. This goes beyond simply observing the HTTP sessions. You can actively fiddle with the data, opening up various possibilities for using Fiddler in multiple tasks.
While we won’t go into listing all of its features today (if you’re interested in learning more, I recommend checking out this excellent blog post by Simona Yaneva), I want to highlight one of its hidden gems: the HEX Inspectors, which offer the ability to interact with raw hexadecimal data.
Fiddler Everywhere provides inspectors crucial in visualizing and structuring captured information from HTTP(S), WebSocket and gRPC sessions. These inspectors serve as UI tools, enabling users to analyze the content of each session through various contextual interfaces. Whether HTTP(S) traffic or WebSocket/gRPC channels, Fiddler offers contextual inspectors to delve into the captured data.
When capturing HTTP(S) traffic, Fiddler presents inspectors for different aspects such as raw HTTP headers, cookies, raw data, preview and HTTP bodies. These inspectors help users gain insights into the specific details of the captured sessions. In the case of WebSocket or gRPC channels, Fiddler goes a step further by providing additional inspectors tailored for WebSocket/gRPC metadata and individual message analysis.
It’s important to note that the data exchanged between client applications and servers may not always be human-readable. While a significant portion of the data is text-based (encrypted but decryptable when Fiddler acts as a MITM TLS proxy), instances where graphical data (for example, images and icons) or specific encoding formats are used. Additionally, some sessions may involve the transfer of binary data that requires processing by the client or server.
Fiddler’s inspectors intelligently detect the format used in each session, allowing users to load the most relevant inspector seamlessly. By simply double-clicking on a captured session, Fiddler Everywhere automatically selects the proper inspector to display the request and response of that session. For instance, if a session contains an SVG image, the Preview inspector will be loaded with a double-click, while a session with a JSON file will activate the JSON Body inspector. This cognitive interface empowers users to quickly analyze received data without worrying about its specific format.
The HEX inspector allows you to analyze fundamental binary data that constitutes the HTTP Request/Response bodies or the WebSocket/gRPC messages. With a HEX inspector, a user can see or edit the raw and exact contents of a body/message, as opposed to the interpretation of the same content that other, higher-level application software may associate with the file format (like an image previewer or a browser that interprets HTML).
One of the most common scenarios to use the HEX inspector is to analyze data corrupted during the client-to-server connection or by system or application program problems.
The data represented in the inspector shows an offset column, followed by a column that holds the raw hexadecimal values, followed by one group of ASCII characters corresponding to each pair of hex values (each byte). Non-printable ASCII characters (like Bell) and characters that will take more than one character space (like tab) are represented by a dot (.) in the following ASCII field.
Let’s demonstrate how Fiddler’s HEX inspector works in real-life scenarios. We will use this gRPC demo written in Python to spice things up. To run the Python demo, you must install pip, grpcio and grpcio-tools. Once the tools are installed, you can clone the gRPC demo.
# Clone the repository to get the example code:
$ git clone -b v1.55.0 --depth 1 --shallow-submodules https://github.com/grpc/grpc
Now, open Fiddler Everywhere and use the Terminal option to start two separate terminal instances. We need two instances to run the gRPC server and the gRPC client. The preconfigured terminal instance is automatically configured to go through the Fiddler Everywhere proxy, so you won’t have to set Fiddler as a system proxy.
In the first Fiddler terminal instance, start the gRPC server:
# Navigate to the "hello, world" Python example for streaming gRPC:
$ cd grpc/examples/python/hellostreamingworld
$ python async_greeter_server.py
In the second Fiddler terminal instance, start the gRPC client:
# Navigate to the "hello, world" Python example for streaming gRPC:
$ cd grpc/examples/python/hellostreamingworld
$ python async_greeter_client.py
The gRPC server and client are immediately streaming messages through a gRPC channel. As Fiddler is configured to capture the preconfigured terminal traffic automatically, we can start inspecting the gRPC traffic on the fly.
Fiddler’s live traffic grid already shows a ton of information—like that the gRPC channel was closed after all messages were streamed and that the connection utilizes HTTP/2 (gRPC is built upon HTTP/2 and won’t work if HTTP/2 support is disabled). We can see the process that generated the session, the timestamps and much more—all that from a simple glance at the live traffic grid columns.
We can now move to the inspectors and focus on the Messages tab. The tab contains all streamed messages between the gRPC server and the client application. The Messages tab provides a context menu with decoding options that you can use to try to decrypt data in unreadable form.
The next step is to select a specific message we want to investigate. As a result, the message data is loaded in the Message > HEX inspector, where we can extract the needed data or quickly see a text representation of the hexadecimal content. Similarly to most hexadecimal viewers, you can save the message content to a file, keep it in the clipboard or copy/paste specific hex parts of the message.
The content that the gRPC server and clients will exchange will often be unreadable. The HEX inspector lets you make a low-level profile of the raw data transferred through the gRPC channels. Even without knowing the proto scheme (which will be the case for every gRPC application you do not own or create), the HEX inspector allows you to deep-dive and analyze captured traffic and make conclusions based on the exclusion and logical assumptions.
Fiddler Everywhere already became a favorable tool for capturing and inspecting online traffic. The cognitive inspectors, the multiple proxy modes, the support for modern-day technologies—all that is just a scratch on the surface in the ocean of possibilities. Of course, the team is constantly working on adding more value, and the best way to move ahead is to share your feedback with us.
Try Fiddler Everywhere and let us know how you feel about it—we welcome you aboard!
]]>All right, all right, all right! We at Progress Telerik cannot advise you on all life challenges, but we do believe we get data presentation and web troubleshooting. Read on if you’re curious what we managed to introduce in our R2 2023 release for you.
Before we get into explaining the introduced features in more depth, make sure you save your spot on the dedicated release webinar. No written text can compete with a live presentation and demo, so I encourage you to save a seat and enjoy our host Sam Basu and our product-specific gurus demonstrating most of the goodies we cover today:
Ok, now to the details as promised!
The year advances, and .NET 8 with it. We have you covered so that you can embed Reporting functionality in your .NET 8 (Preview) applications. Yes, the Windows-only limitation should be mentioned here, but stay tuned for our next big release. I believe news is coming.
The REST report service that enables all HTML5-based web report viewers, the Native Blazor Report Viewer, and the desktop report viewers for WPF and WinForms are all compatible with the new framework version. For your convenience, the Telerik Reporting installer deploys a dedicated set of sample projects targeting .NET 8 Preview 4.
Report authors can now easily convey key metrics or performance indicators by using a new Gauge report item. It supports displaying radial gauges. The gauge contains a needle representing the desired value and one or more value ranges represented by arcs. The arcs are defined by their minimum and maximum threshold values and can have different styles. The value of the gauge can be data-bound using an expression. Additionally, all min and max values defining the arcs can also be data-bound. This dynamic and interactive element enables users to quickly assess progress, compare actual values against targets, and identify areas that require attention.
Accessibility is a must for us because it is a must for you. Based on your valuable feedback, we revisited our export of PDF documents and improved them. In particular, we improved the structure elements and structure tree generation of the generated document. What that means is that each text span and image and drawing in the document belong to a semantic tree so that assistive technologies such as screen readers know it and allow better navigation among the information. Simple.
This means the produced documents now meet the requirements of the PDF/A-1a (“a” for accessibility) standard, and this is what we write as a document as a claim.
The Angular Report Viewer in Telerik Reporting received an update in terms of compatibility and now supports the Ivy rendering engine, which is mandatory as of Angular 16. Effectively, users can seamlessly integrate the Angular Report Viewer into their applications built on Angular 13+, ensuring a smooth and consistent user experience. Note that Angular versions prior 13.0.0 are not supported because of this change.
We improved the ARIA (Accessible Rich Internet Applications) support in Telerik Reporting significantly. On the web, when accessibility is enabled, the rendered report items now contain predefined accessibility roles. This way they conform better to the ARIA standard, bringing a better reporting experience for all users, regardless of their abilities.
The report author can use a dedicated AccessibleRole property on each report item to customize the assigned accessibility role, bringing even more specific content to the users. The assigned value can be a constant string or be data-bound to the item’s data context.
The Table item rendering on the web is now rendered as a hierarchy of elements so that the assistive technologies recognize it as table content and present it with better support for screen readers, keyboard navigation and assistive technologies.
Previously, we introduced a .NET 6 build of the comprehensive Standalone Report Designer for authoring reports on a desktop. One important tool that was missing from that tool is the SQL Query Builder enabling mouse-only SQL query composing. We managed to build the necessary dependencies for .NET and introduce this experience for the clients targeting .NET in their applications. The only small limitation is that this version of the Query Builder does not automatically retrieve the relations between the database tables, so JOIN fields should be selected from the respective dropdowns.
The release also brings a quality-of-life improvement in assembly resolution which is set up in the application configuration file. This enhancement simplifies the configuration of resolving and loading extensibility assemblies for the Telerik Reporting report generation engine. The developer can now only use the name of the target extensibility assembly instead of its file name. This streamlined approach not only improves the efficiency of assembly resolution but also provides flexibility in managing dependencies and resolving potential conflicts.
Report Server received numerous fixes and quality-of-life UI changes that improve the overall experience while managing the server assets, and I will list the most significant ones:
We had to make the decision to end support for the Silverlight Report Viewer and its associated WCF Reporting Service. This strategic move aligns with the industry-wide shift toward modern web technologies and reflects our commitment to providing cutting-edge reporting solutions.
With the discontinuation of support, we encourage you to transition to alternative reporting viewers that leverage newer frameworks such as HTML5 and Blazor. This transition ensures compatibility with current browsers and enables the end users to take advantage of the latest reporting features and performance improvements.
Fiddler Everywhere provides a Rules Grouping functionality that allows easier workflow and better organization of rules based on your scenarios. The feature supports multiple levels—from single rules to groups and subgroups—which you can easily achieve using drag and drop. The improved rules view also lets you apply actions in bulk including enabling, disabling, executing, reordering and more.
You can now capture gRPC traffic (in beta) and troubleshoot applications that use this framework out of the box with Fiddler Everywhere. The gRPC traffic will be visualized in the Live Traffic with a specific icon and can be further analyzed in the Trailers tab of the Response body in the Inspectors.
Fiddler Everywhere will use by default the higher TLS 1.3 version which is now supported in the app. While establishing the HTTPS connection, if the client and/or the server support TLS 1.3, Fiddler Everywhere will select/suggest it and indicate the version and needed info on multiple places in the app.
Fiddler Everywhere now offers one more alternative way for capturing HTTPS traffic without trusting the Fiddler Root Certificate. The latest Terminal option allows you to capture traffic from other locally run cURL, Node.js and Python apps and proxy all requests to Fiddler Everywhere. The supported terminals are:
Add custom-made columns to the live traffic grid and set filters to them to ease the traffic inspection process in Fiddler Everywhere:
You can also find the following security improvements recently added to Fiddler Everywhere:
We are introducing a new offline mode in Fiddler Everywhere that will allow you to use the application in an isolated environment with limited or no internet access. If your setup requires the need of such offline support to perform traffic inspection and debugging analysis, reach out to telerik-sales@progress.com to learn more about the functionality.
I appreciate that you made it to this point in the blog post. This means you, just like us, believe in the importance of using the right tools for the right job. I hope you found what you need and will give a try to some or all of our products:
]]>One of the most common things that all IT engineers do is to work with HTTP requests and responses. Whether you are creating a web application, backend service, dedicated API, online game or desktop software, there is a good chance that you will have to compose, execute, capture, test and investigate HTTP sessions. And during that investigation, common questions appear:
To help you find the answer to similar questions, Fiddler Everywhere introduced a feature called Compare Sessions.
Fiddler Everywhere is a local proxy and web debugging tool that captures HTTP(s), WebSocket and gRPC traffic and provides multiple inspection instruments. Learn more about Fiddler here.
This article shows you how to use the Fiddler Everywhere proxy to compare two or more sessions with a few clicks. No need to use external diff tools. And the great part—it’s as simple as Click > Add > Compare!
After Fiddler Everywhere captures the ongoing HTTP(S) traffic, we can immediately use Fiddler’s inspectors to investigate the data. As powerful as the inspectors are, there is a case where you would like to compare several sessions next to each other simultaneously. In the past, we had to use an external diff tool to achieve that, which was inconvenient. The Compare Sessions tab solves that problem and empowers you to compare two sessions or groups of multiple sessions.
Fiddler users can now compare API calls by any data contained in the HTTP requests and responses. Using the new Compare Sessions tab to compare two HTTP(S) sessions is as easy as selecting them and using the Compare in Fiddler Everywhere option from the context menu. You can compare entries from the Live Traffic grid or a saved session snapshot.
Then you can inspect the selected sessions in a new Compare Sessions tab.
The above demonstrates how you can compare two sessions within a fraction of a second without leaving Fiddler Everywhere. The comparison is made line by line, highlighting any difference in the HTTP headers and bodies. Fiddler uses the color red to highlight a change in the “original” session (the session that resides in Group 1) and green to highlight a difference on the same line in the subsequent session (the session in Group 2).
Fiddler Everywhere expands the comparing feature while providing an option to load and compare multiple HTTP(S) sessions. Similarly to comparing two entries, Fiddler enables you to add more sessions in two comparing groups (Group 1 and Group 2). You can add captured HTTP(S) session anytime through the Add to Compare Group option from the Live Traffic context menu.
While using the Compare Sessions tab, we recommend switching the Fiddler layout to a horizontal format. This way, you will be able to select/deselect different sessions to compare quickly, and, at the same time, you will be able to see side-by-side the HTTP Request and HTTP Response inspectors that are comparing the selected entries. The UI layout changes through the Switch Layout button (located in the Live Traffic menu—to the right of the Quick Search field).
The Fiddler UI lets you quickly switch between the added sessions, enabling you to make deep-dive analyses of multiple entries with a single click. You can easily remove a session from the comparing group or show its original location in the Live Traffic grid.
You will find additional options to improve your workflow in the top-right corner of the Compare Sessions tab.
The Match Sessions By option changes the comparison order condition. The possible choices are to match by URL (default condition) or by Order. The latter compares sessions by the order they appear in the comparing groups, whereas the former matches identical URLs.
Use the Ignore Headers option to reduce the comparison highlight and make the wanted data easier to find. The functionality allows you to create an exclusion list to limit which HTTP headers should be compared. Any header included in the exclusion won’t proceed during the comparison.
Additionally, you can use Reveal in the Original List (session’s context menu) to quickly return to the origin and use the Overview or Inspectors tabs to deep-dive into the sessions’ data. The Overview tab provides statistical data for the session’s timings, sizes and event timestamps. The Inspectors tab is a set of UI instruments to visualize the content of each HTTP request and response.
The Compare Sessions function was born out of necessity to ease users’ web debugging journey. Each new release of Fiddler Everywhere adds more value to the product, and we are constantly pushing forward our aim—to make Fiddler Everywhere the most intuitive and valued proxy tool there is. Newly released features like HTTP/2, gRPC, TLS 1.3 and rules grouping are just a hint of what more you can expect in the future.
So all that said, the Fiddler team awaits your feedback! We are eager to know what you want to see as the next big thing in Fiddler Everywhere.
]]>Fiddler Everywhere from Progress Telerik evolved from the concept of being just a web-debugging tool that acts as a system proxy. Nowadays, the term “proxy tool” is way too narrow to describe the many possibilities that Fiddler opens. A more correct depiction is one of a Swiss Army knife proxy tool for meddling with HTTP(S) traffic daily.
The complexity of Fiddler’s functionalities implies that there is a learning curve to using Fiddler to its full potential. However, the team behind Fiddler Everywhere works in the opposite direction. The main goal is to make the tool easier to use and more intuitive while having cross-platform functional coverage.
While reviewing the user’s feedback, it quickly became apparent that setting Fiddler as a system proxy might be challenging for many users due to inconvenience or administrative limitations. Users wanted to work with sandboxed environments that would allow them to quickly test their HTTP(S) requests without changing the system network settings or configuring a proxy manually.
Using sandboxed proxy tooling solves several issues:
The above arguments were good enough for the core Fiddler Everywhere team, and they led to the appearance of exciting new features—the preconfigured browser capturing and the topic of this article— the preconfigured terminal capturing.
Today almost all software engineers use a command-line interface (CLI) to work with various applications quickly. And nearly all applications have online connectivity. Most of us use CLI to build, test and deploy applications executing HTTP(S) requests. It was only natural for Fiddler Everywhere to provide a preconfigured terminal instance that automatically redirects the HTTP(S) traffic through the Fiddler proxy.
To open a preconfigured terminal instance, use the Terminal button from the Live Traffic toolbar.
The option opens the preferred terminal on your OS (you can set up the preferred terminal upon the initial startup). The following terminals are supported:
Once the terminal instance starts, its environment variables are updated to use Fiddler Everywhere as an HTTP and HTTPS proxy. Node.js will use global-agent, the Fetch API will be patched to use Fiddler’s proxy, and cURL requests will be executed with the -k flag (which disables attempts to verify self-signed certificates against a certificate authority). Fiddler Everywhere won’t change any global variables, so any other terminal instance won’t go through the proxy (unless explicitly set). The preconfigured terminal instance will have network connectivity as long as Fiddler Everywhere works.
Windows PowerShell specifics: By default, most terminals won’t differentiate localhost traffic, so in most cases, you will capture localhost traffic out of the box. However, this is not true for Windows PowerShell because it is built upon .NET. The .NET Framework is hardcoded not to send localhost requests through any proxies, and as a forward proxy, Fiddler will not receive such traffic. Windows PowerShell uses the .NET Framework (not to be confused with PowerShell, which uses .NET Core), so the localhost traffic is not automatically sent through the proxy. To work around the issue, use the Fiddler’s aliases or add a dot to the end of the localhost address (for example, localhost.:8080).
.NET specifics: To capture traffic from cURL or Node.js libraries, you don’t need to explicitly install and trust the Fiddler root CA (certificate authority) on the Fiddler host. However, this is a mandatory requirement for a .NET application that executes HTTPS requests (as a .NET application will utilize the system keychain). In case you haven’t installed and trusted the Fiddler root CA, learn how to do it here.
Once the default terminal starts, you can immediately start testing your applications. Below, you will find basic demonstrations depicting how Fiddler’s Terminal captures traffic from a Node.js app that uses the https library, from an app that uses the Fetch API, and from a cURL request.
const https = require('https');
https.get('https://jsonplaceholder.typicode.com/users', res => {
let data = [];
res.on('data', chunk => {
data.push(chunk);
});
res.on('end', () => {
const users = JSON.parse(Buffer.concat(data).toString());
for (user of users) {
console.log(`Got user with id: ${user.id}, name: ${user.name}`);
}
});
As a result, you can quickly inspect, debug, test, and mock different HTTP(S) scenarios with a few clicks.
fetch('https://jsonplaceholder.typicode.com/comments')
.then((response) => response.json())
.then((json) => console.log(json));
curl -k -i "https://api.nasa.gov/planetary/apod?api_key=DEMO_KEY"
Built-in support for Fiddler proxy with Python applications is in active development and is just around the corner. Do you have other ideas on further improving the preconfigured terminal option? Don’t hesitate to leave feedback and tell us about the features you want to see in Fiddler Everywhere.
]]>The initialism “gRPC” is around us more and more often each day. We are hearing that large companies like Google use gRPC (this is to be expected as “gRPC” stands for “Google Remote Procedure Calls”), plus others like Netflix, Spotify, Salesforce, IBM, Cisco, Dropbox and Slack—the list goes on and on.
So what exactly is gRPC, and how does it help developers today?
Technically, gRPC is a Remote Procedure Call (RPC) framework that can run in any environment. It can also be referred to as an architectural style similar to REST, SOAP, WebSockets, etc. While most applications in the wild still rely primarily on REST, it became apparent that the REST API is far from perfect, and relying only on it could be problematic as your business grows. The mass adoption of the microservices architecture style also showed the need for a different technology to solve various problems.
This is where gRPC came in! The gRPC framework is efficient, has high performance (some say up to seven times faster than REST), is cross-platform, has a native code compiler, and is ideal for microservices and data streaming. gRPC is not here to replace REST but should be considered an alternative for solving specific problems.
Looking into the framework itself, the first thing that we can notice is that it uses the Protobuf format (instead of JSON or XML). The pros of the format are that it is light and compressed (here is where the gRPC gains high performance). The cons are that Protocol Buffers messages are not human-readable.
Fiddler Everywhere from Progress Telerik can help developers who own the .proto file—each Protobuf message is available with Fiddler and can be used for deep-dive investigation.
As gRPC gained popularity, it became apparent that developers needed a debugging tool to help them capture and inspect gRPC traffic. The tool had to support HTTP/2 (because gRPC is based on HTTP/2 and is not compatible with HTTP/1.1) and also has to be ready to visualize the information from specific gRPC channels, including a handshake, messages, trailer headers, etc. Wait no more ...
Fiddler Everywhere to the rescue!
After the Fiddler team recently introduced support for HTTP/2 and TLS 1.3, it was natural to go ahead with the implementation for gRPC support. With Fiddler Everywhere version 4.2.0 and above, gRPC support is a reality, and you can start capturing and inspecting its traffic out of the box. OK, not precisely out of the box—because the gRPC API relays on HTTP/2, you must ensure that your Fiddler Everywhere application has HTTP/2 capturing enabled through Settings > Connections > Enable HTTP/2 Support (BETA).
That’s all you need from Fiddler Everywhere’s side!
The next step is to tell your gRPC client application to respect Fiddler’s proxy for its HTTP and HTTPS requests. The specific proxy configuration entirely depends on the used client’s application technology (for example, different approaches if it is a Python app, a GO app, a Java app and so on). Learn more on how to set Fiddler Everywhere as a proxy for your technology here.
Upon capturing a gRPC session, Fiddler Everywhere shows opened and closed gRPC channels in the Live Traffic list. A green badge in the ID column (by default, the first column on the left) indicates an active gRPC channel, while a red badge indicates that the gRPC channel is closed. Fiddler Everywhere supports all gRPC lifecycles and will successfully capture unary RPC, client streaming RPC, server streaming RPC and bidirectional streaming RPC.
You can select a session with a single click to observe the Handshake tab and its details. The Handshake tab contains information about the used HTTP headers and the specific gRPC trailers. The server sends trailers to the client after processing the request. A typical scenario is for trailers to contain information common to service methods.
You can open the Messages tab by double-clicking on the selected session (or by manually selecting the tab) and inspect each streamed message in the gRPC channel. Each gRPC message uses the Protobuf format, which is in unreadable form and received as binary.
You can inspect the binary message from the Message inspector. Fiddler Everywhere also provides instruments (Decode value and HEX inspector) to partially visualize text content that could be part of the Protobuf message. It is important to note that this will always be the raw Protobuf content that was captured over the wire, not the decoded values of the message fields. Only the creator and owner of the .proto scheme can fully decode a Protobuf message. In a future release, we will be adding the possibility for providing a .proto schema to Fiddler Everywhere for automatically decoding the Protobuf messages.
gRPC is here to stay—in 2022, the technology gained popularity and increased its spread (from 8% to 11% percent of developers who said they like gRPC). It is now one of the most recognizable architectural styles alongside REST, WebSocket, SOAP, Webhooks and GraphQL. It is likely that a programmer will have to deal with it sooner or later, and Fiddler solves that potential puzzle.
Fiddler Everywhere itself evolves more after each release and is far from being just a forward proxy or a web debugging tool. The added gRPC support, alongside the support for other modern technologies like HTTP/2, TLS 1.3, the advanced Rules capabilities, HTTP Request composer, collaboration and many more, make Fiddler a Swiss Army knife for solving a different range of tasks.
For QA engineers and developers, support personas, web administrators, policy enforcers and security experts, Fiddler is a tool that can bring much value. Did we mention that Fiddler is cross-platform? Yes, it works on macOS, Windows and Linux and can capture traffic from virtually any client that uses the HTTP(S) protocol.
In case you have just heard about us—the team welcomes you! Go ahead and try Fiddler Everywhere and let us know what you think!
]]>Almost all modern-day webpages, plus many desktop and mobile applications, use the HTTPS protocol to secure communication from the client to the server and vice versa. The S in HTTPS stands for Secure and implies that the data is transferred not in plain text but in encrypted form.
The encryption in HTTPS is achieved by using a cryptographic protocol named Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The idea is to prevent an intermediate from sniffing the ongoing packets and obtaining sensitive data (like usernames, passwords, financial data, personal content, etc.)—cryptographic encryption ensures that all data is unreadable for third parties.
There is widespread support for TLS versions TLS 1.2 (in use since 2008) and TLS 1.3 (released in August 2018), which are considered a standard for creating a secure application. Older versions of TLS (TLS 1.0 and TLS 1.1) were discontinued in 2019 and, alongside the obsolete versions of SSL (SSL 2.0 and SSL 3.0), are considered insecure.
If you are writing an application today and wondering which TLS version you should use, go for TLS 1.3! The latest version of TLS has significant improvements such as:
In conclusion, TLS 1.3 provides better handshake performance, improved latency and more robust security.
By default, Fiddler Everywhere by Progress Telerik is a local forward proxy, capturing non-secure HTTP traffic. To enable capturing and decrypting of HTTPS traffic, you need to go a step further and allow Fiddler to decrypt TLS traffic by explicitly installing and trusting its root CA and enabling HTTPS capturing. Once the Fiddler CA is trusted, the proxy works as an intermediate TLS proxy.
The above depicts how Fiddler Everywhere acts as a server for the client (that sends the HTTPS request) and as a client to the server (that receives the HTTPS request and returns the HTTPS response).
It is important to note that Fiddler will negotiate the TLS connections with the client and the server separately. When the Fiddler proxy establishes the TCP connection, it uses the client’s TLS version. Then Fiddler negotiates the TLS version with the server. If the server supports the client’s TLS version, it will select it for the connection—otherwise, it will negotiate a lower version. The latest version of Fiddler Everywhere will always try to use TLS 1.3 as the default TLS version.
Fiddler Everywhere 4.2.0 officially introduced support for TLS 1.3. Note that Fiddler Everywhere will accept inbound connections using any protocol version, including obsolete ones, but only if the host operating system or client app allows them. (All supported versions are SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 and now TLS 1.3). However, there is specific behavior when the proxy stands in the middle and if the client and server are negotiating different TLS versions.
Suppose the server does not support TLS 1.3. In that case, Fiddler will negotiate a different version (through the Fiddler-Server TLS handshake in steps 7 and 8 depicted above) and establish the connection using a lower TLS version. In that case, the connections between the client and Fiddler and between Fiddler and the server will use different TLS versions.
The above behavior leads to a significant implication—Fiddler can unexpectedly "fix" your application while it fails in real life! Let’s demonstrate the above while using the BadSSL endpoint.
https://tls-v1-1.badssl.com:1011/
By default, Windows 10 does not allow an app acting as a server or proxy (like Fiddler Everywhere) to support TLS 1.3. To test TLS 1.3, you must execute the request from a compatible OS (Windows 11, the latest macOS or Ubuntu) and a client supporting TLS 1.3.
As a result, when Fiddler Everywhere stands in the middle, it will establish a TLS 1.3 handshake with the client. Then it will try to negotiate a TLS 1.3 handshake with the BadSSL server. However, the server will downgrade the TLS version to TLS 1.1 (as it explicitly supports that version). In Fiddler Everywhere, you will notice different badges that inform you of the TLS versions used for the HTTP Request and HTTP Response.
The direct implication is that you will be able to successfully load the BadSSL page because, as an intermediate, the Fiddler proxy successfully negotiated the TLS version with each of the parties (client and server).
When Fiddler is not in the middle, you might hit an unsupported protocol error (like ERR_SSL_VERSION_OR_CIPHER_MISMATCH) if the client and the server don’t support a standard SSL/TLS protocol or cipher suite.
The support for all TLS versions in Fiddler Everywhere opens many possibilities. You can create and apply specific rules for endpoints using a particular SSL/TLS version, inspect detailed TLS-related information (extensions, ciphers, compression), or filter your traffic through the TLS Version column.
And this is just the beginning! The team is planning to provide options to extend Fiddler’s TLS capabilities. Features like setting custom TLS versions and using specific cipher suites are just some things you could expect from Fiddler Everywhere in the future.
Try it yourself—download a free trial of Fiddler Everywhere.
]]>Carl Franklin and Richard Campbell host .NET Rocks—1800+ podcast episodes later, .NET Rocks continues to educate and entertain developers on latest technology trends. The most recent .NET Rocks show dived into all things Fiddler—the history, evolution and what lies ahead for the popular network debugging tool.
To say .NET Rocks has been one of the most popular podcasts would be an understatement—so many developers grew up with .NET Rocks. The late night drives from a customer site/user group meeting, the early morning walks/jogs, the working lunches—so many of us have had .NET Rocks playing in our ears over the years. With production always being top notch, .NET Rocks has informed, educated and entertained developers for the past two decades. Cheers, Carl and Richard, for years of knowledge bites and chuckles.
A recent .NET Rocks episode had Rosen Vladimirov and yours truly on to talk about Fiddler—another thing that so many developers have grown up with. From humble beginnings, Fiddler has evolved into a big family of products serving various users/teams with differing needs. While the popularity of Fiddler has meant developers have had Fiddler as a default part of their development toolset, recent Fiddler updates embrace latest network technologies and open up the tooling to QA/Support/end users. The .NET Rocks show was a great discussion on Fiddler basics to the current reality and what the future holds for a beloved tool—give it a listen, people.
Turns out, you and me happen to be in Dubai at the same time. We’re taking the elevators up at the Burj Khalifa—the tallest building in the world. At the ground floor, you run into me—a long time Fiddler user and aficionado. You’ve heard about Fiddler, but haven’t tried things as of late. We’re headed to the top of the Burj and I have an elevator ride to convince you to try Fiddler. Ask me anything. However, I am eating a yummy sandwich on the way up, so my responses will be super short in between bites. Let’s go!
Q: What is Fiddler exactly?
A: Fiddler is a popular network proxy with endless debugging and troubleshooting capabilities.
Q: I’ve heard Fiddler is not just one thing any more?
A: Yes, Fiddler is a family—Fiddler Everywhere, Fiddler Classic, Fiddler Jam, Fiddler Cap and Fiddler Core.
Q: I’m told Fiddler has always worked great on Windows.
A: Yup, it’s called Fiddler Classic—no one is moving your cheese.
Q: Does Fiddler Everywhere really work everywhere?
A: Yes, cross-platform with consistent UX on macOS, Windows and Linux.
Q: What are some things developers like in Fiddler Everywhere?
A: Choreographed Filtering/Searching of network traffic, nimble API Composer and robust Rule Builder.
Q: What’s Fiddler Jam exactly?
A: Chromium-based browser extension—helps triage user issues by capturing traffic details.
Q: Can I include the power of Fiddler engine inside my apps?
A: Yup, Fiddler Core is an embeddable .NET library.
Q: Anything new with HTTP these days?
A: Fiddler allows for capture/inspection of HTTP/HTTPS traffic with latest HTTP2 support.
Q: What’s the latest in the network layer?
A: Fiddler Everywhere 4.2 now supports TLS 1.3 encryption protocol.
Q: What if I’m dealing with low-level bidirectional traffic?
A: Fiddler has baked in support for WebSockets—brings your AI chat apps.
Q: Will Fiddler work if I’m building MicroServices?
A: Latest Fiddler Everywhere has beta support for capture/inspection of gRPC traffic.
Q: Unlike web, native mobile/desktop apps are hard to test.
A: Fiddler can capture traffic for iOS/Android/Windows/macOS—essentially any native app through configured proxy.
Q: How can teams use Fiddler?
A: Sessions, Requests, Rules and Jam captures can all be shared for ultimate productivity.
Q: Looks like Fiddler is solid and getting better each release?
A: Yup. Fiddler is used by hundred of thousands of developers/enterprises—you should give it a spin.
Fiddler promotes a holistic debugging and troubleshooting approach that is radically intuitive—for developers, QA testers, support engineers and users. No matter what the app or platform, nobody should be in doubt as to what’s happening in the network layer—the Fiddler family of products can help.
Looks like we’ve reached the top floor of the Burj Khalifa. I see a smile on your face—looks like you’re convinced and ready to try out Fiddler. I also see a lounge—let’s go have a drink and explore the views of possibilities. Ciao.
]]>