ven though the hit is described by FxM as being a page or page element and the hit size suggests that there should be HTML date the only message shown is:
"Zero request content body bytes were captured for this hit; see Hit Details for headers, etc."
"NOTE: Please see 'Captured Request Body Types' under 'Hit Analysis Configuration Options' for details
on configuring the capture of request content that is not URL-encoded form data."
The application creating the content-type for the header is specifying an incorrect content-type.
The packet content-type is marked as some from of HTML but the actual data is something else.
And example of this can be seen here.
<?xml version="1.0" encoding="UTF-8"?><server><requests><Session.openRq UserName="xxx" Password="" /><ManuScript.getValueRq manuscript="xxxxxxxxxx-xxxx-xxxx-xxxxxxxx-xxxxxxxxxxxx"><session><data><policy invoking_application="PRQ" policy_status="" is_customized="Y" call_type=""><profile at_residence_date="2012-02-01T00:00:00" call_type="purchase_call" original_created_date="" generated_on="" policy_number="" state_code="IN" zip="xxxxxx" territory_id="0" territory_cd="0"
If incorrect content-type information is given to FxV, it cannot decode the content.
There was a time when FxV did try to figure out the body without looking at the header type, but with the proliferation of data types it became impossible to program a reliable identification methodology that would handle all permutations, it borders on AI.
FxV has no idea what coming across the wire and can't make assumptions so it needs to use the header.
The issue is external to FxV, the application creating the packets must be corrected to set the correct content-type.