Version 184.108.40.206 of the FiddlerCore .NET class library has been released. This new version includes a number of new features that make FiddlerCore more useful for a variety of traffic monitoring and capture scenarios. With the exception of the final improvement (Server Read Callback), all of these improvements are also available to extensions running inside the full Fiddler application.
Server Certificate Validation
FiddlerCore hosters will now have the opportunity to accept or reject the server-provided certificate when a HTTPS connection is made and traffic decryption is enabled. This enables a number of new scenarios:
- Collection and storage of server-provided certificates
- e.g. analyze how many certificate chains are signed with MD5
- Acceptance of certificates based on any criteria
- e.g. treat my development certificate as valid for every site
- Rejection of certificates based on any criteria
- e.g. do not accept certificates from government CAs
You can attach an event handler for certificate validation thusly:
And implement it like so:
If you do not implement this method, or you return false, unless Fiddler.CONFIG.IgnoreServerCertErrors is set to true standard certificate validation rules will be respected.
Update: This event was not designed correctly and has been changed in Fiddler/FiddlerCore 220.127.116.11 and above. The event has been renamed to OnValidateServerCertificate which is passed a ValidateServerCertificateEventArgs object. An extension may set the ValidityState property of this object to any of the CertificateValidity constants.
Prevent Storage of Streaming Traffic
A common scenario for FiddlerCore-based applications is to act as a traffic monitor only, looking only at the request and response headers. The log-drop-request-body and log-drop-response-body flags can be set on a session to ensure that the request and response body are discarded once the request is sent and the response is returned, but these flags only take effect when the response is completed. In the case of streaming data (e.g. an unending Internet radio feed) the hosting application’s memory usage will continue to grow unbounded because the response is never completed.
If a response is streamed (e.g. oSession.bBufferResponse == false) and the log-drop-response-body flag is set, FiddlerCore will discard traffic as it streamed to the client. Alternatively, you can use the following code:
…to set the have FiddlerCore discard streamed response data in all sessions, even without the log-drop-response-body flag.
Of course, if your application is not storing response data for examination, you typically should also set the preference:
…to ensure that FiddlerCore will stop reading from the server if the client closes the connection to the FiddlerCore proxy during streaming.
In very rare cases, it may be useful for an application to receive notice as each block of traffic is downloaded from the server. This raw data buffer is nearly useless for most applications because it provides none of the parsing conveniences available elsewhere in the Fiddler API. HTTP response headers and the response body are not delineated, and compressed/chunked traffic are not decoded or unchunked. However, for certain uses (e.g. counting the raw number of bytes received while streaming) this capability may be useful.
Register for this callback like so:
You can view or modify the bytes received like so:
The RawEventArgs parameter contains four members: arrDataBuffer, iCountOfBytes, sessionOwner, and AbortReading. arrDataBuffer is a fixed-size byte array. iCountOfBytes is an integer indicating how many bytes of the arrDataBuffer array have been set by the read from the server. sessionOwner is a reference to the session for which the response is being read. The AbortReading member is a boolean which can be set to request that the read from the server be terminated as soon as possible.
Fiddler 18.104.22.168 introduced a new Import/Export Architecture to simplify the transcoding of Web traffic to and from multiple formats. FiddlerCore now supports this architecture, and provides default implementations for the Sesssion Archive Zip format.
You can direct FiddlerCore to load additional ISessionImport and ISessionExport classes from either your application’s assembly, or from the assembly of your choice. For instance, the following code will load the transcoders from Formats.dll in your application’s directory.
It is important to note that FiddlerCore’s ISessionImport and ISessionExport interfaces are source-compatible with those in the Fiddler application, but they are not binary-compatible. If you want to share transcoders between a FiddlerCore application and Fiddler itself, you will have to compile your code into two individual assemblies, one Referencing Fiddler.exe and one Referencing FiddlerCore.dll.
The FiddlerCore package includes two source files, SAZ-DotNETZip.cs and SAZ-XCEEDZip.cs either of which will allow FiddlerCore-based applications to load and save SAZ-formatted archives. The former class requires the open-source DotNETZip library while the latter is based on the commercial XCeed Zip library.
To import sessions from a file in SAZ format, you can write code like so:
To export a set of sessions to a file, you can write code like so:
If desired, you may download and redistribute a FiddlerCore-compatible version of the BasicFormats assembly (supporting Import/Export of HTTP Archive JSON and HTTP Archive XML, and Export of Visual Studio Web Test XML, WCAT Load Test Scripts, and Raw Files).
I hope you find these new capabilities useful in building your applications. Please let me know if you encounter any problems!