Hello,
on my ACE module I have simple policy which distributes http requests to several backend servers.
class-map match-any VIP-DACP-WEBSERVICES
2 match virtual-address 10.105.56.17 tcp eq www
policy-map type loadbalance first-match VIP-DACP-WEBSERVICES
class class-default
serverfarm DACP-WEBSERVICES
insert-http x-forwarded-for header-value "%is"
policy-map multi-match DACP-WEBSERVICES
class VIP-DACP-WEBSERVICES
loadbalance policy VIP-DACP-WEBSERVICES
Sometimes HTTP request are damaged on the ACE. It means that content of the message which goes from ACE to backend rserver looks different than original message from client to ACE.
Corrupted data are always inside of <binaryData> code.
Original data to ACE:
<binaryData xmlns="http://www.cpoj.cz/dacp/xsd/comImportDocPageRequest">
SGzhmmVu7SBvIHpwcmFjb3bhbu0gc291Ym9ydSBwcm8gc3Rvcm5vIFBvZHNtbHV2
IHByb2R1a3R1IEFMDQoNClByb2NlcyB6cHJhY2924W7tIHNvdWJvcnUgVElBQUw0
OTAyMTkyMzEyMTQxMTIxX1MwMS5jc3YsIHBybyBy4W1jb3ZvdSBzbWxvdXZ1IOjt
c2xvIDQ5MDIxOTIzMTIgc3B1mnTsbv0gZG5lIDIyLjExLjIwMTQNVElBIGRvcGFkbCBzIG7hc2xlZHVq7WPtbSB2/XNsZWRrZW06DQoNCiAgIENl ...
Corrupted data from ACE to backend:
<page mimeType="text/plain" fileName="">
<binaryData xmlns="http://www.cpoj.cz/dacp/xsd/comImportDocPageRequest">
SGzhmmbu0gc291Ym9ydSBwcm8gc3Rvcm5vIFBvZHNtbHV2
IHByb2R1a3R1IEFMDQoNClByb2NlcyB6cHJhY2924W7tIHNvdWJvcnUgVElBQUw0
OTAyMTkyMzEyMTQxMTIxX1MwMS5jc3YsIHBybyBy4W1jb3ZvdSBzbWxvdXZ1IOjt
c2xvIDQ5MDIxOTIzMTIgc3B1mnTsbv0gZG5lIDIyLjExLjIwMTQNCnWeaXZhdGVs
ZW0gVElBIGRvcGFkbCBzIG7hc2xlZHVq7WPtbSB2/XNsZWRrZW06DQoNCiAgIENl ...
Differences in original and corrupted request are marked by red. Corrupted data are always 18Bytes long (there is CR LF between ..Vs and ZW0g in corupted data example)
I already experienced similar issue couple of months ago (see https://supportforums.cisco.com/discussion/12245716/ace30-damages-http-request )
But in current situation http messages are smaller (approx. 4000B).
I've tried to apply following parameter map but nothing has changed.
parameter-map type http DACP-WS-PARSE
set header-maxparse-length 65535
set content-maxparse-length 65535
length-exceed continue
parsing non-strict
Petr
