From my prior experience I have seen similar issues with firefox.
Please try using firefox for reproducing the issue and get the output for below :
show np 1 me-stats -shttp
Look for counter value
Exceed max buffer errors: 16901 <<<<< Check if the counter increase after the test.
you can try few times and in case if you see the value increasing for “ Exceed max buffer errors”
I believe if you do the following and test that should fix it.
configure set header-maxparse-length 65535 and set max-parse-time 65535 and set content-maxparse-length 65535
host1/Admin(config)# parameter-map type http http_parameter_map
host1/Admin(config-parammap-http)# set content-maxparse-length 65535
host1/Admin(config-parammap-http)# set max-parse-time 65535
host1/Admin(config-parammap-http)# set header-maxparse-length 65535
host1/Admin(config-parammap-http)# length-exceed continue
Apply the above in multimatch policy :
appl-parameter http advanced-options http_parameter_map
I applied your suggested config and it resolved the problem I was having with posting large content using Firefox.
But "set content-maxparse-length 65535" seems to set the maximum content to 65535 bytes, but I'm able to post content way larger than that. How does this work? Is "length-exceed continue" a factor in this??
Good to hear that the document was helpful. Yes your assumption is correct "length-exceed continue" allows packet bigger then the limit.
When you say content max parse length that means ACE will parse and read the packet till that length to match to a class map. In this case ACE will stops parsing after the defined max-parse length 65535 but will continue accepting the data beyond the limit.
hope that helps.
Thank you very much for your response.
In this case, is this config "set content-maxparse-length 65535" really necessary?? If yes, why this number and not another?
Isn't something like this "length-exceed continue" enough??
And how is this related to the Firefox browser, why other browser don't have this problem??
Sorry for my many questions, but I didn't see anywhere a clear explanation of this bug, I don't want to abuse of your kindness.
Not really necessary. If you are doing L7 and the match comes within few bytes then you can reduce that to a lower value. Parse length is just to set a limit for the ACE to read till that length.
Yes, The length-exceed continue should be enough. You can do a quick test. I would appreciate if you keep me updated with the result.
Hope that helps.
I used "length-exceed continue" only in a parameter map and Firefox failed again to post large http content (the default content parse being 4096 bytes).
I first changed the parameter map to:
parameter-map type http HTTP-PARAM-MAP
set header-maxparse-length 65535
and second time to:
set content-maxparse-length 65535
and in these both cases it worked. I can probably play with this length to find the right one so I won't put too much pressure on the ACE, parsing 65535 bytes every time, but I still need to understand what's the connection with Firefox browser. Do you know why Firefox behaves this way??
I would like to keep this question open..
We encountered this exact problem, we had been runnning a ACE10 and upgraded to ACE30 and this was the only issue we had after the upgrade (minus some obvious default config issues)
Opera and Firefox seems affected - but not IE and Chrome...
This happened on a SSL proxy in front of a forum - Firefox users would fail when the hit "reply" but normal browsing the forums was not affected
we now use:
parameter-map type http FIX_FIREFOX
What is the obvious downside of using this ?
Thanks a lot for your posting on the forum. We have upgraded last weekend from ACE20 to ACE30 had the same issue with one of applications. Actually we could reproduce the issue on any modern browser (Firefox, Chrome and IE). I think the Cisco set limits for headers and content are too small for todays applications.
I have implemented the proposed settings and subjective the performance of the application has dramatically increased and as well the issues are gone (performance test of our programmers is currently ongoing).
Again, thanks for the great help.
Good to know that it was helpful.
i was trying to resolve this problem adding http parameter to my configuration. But the problem still exist.
Version A2(2.0) [build 3.0(0)A2(2.0)]
parameter-map type http HTTP_PARAMETER_MAP
"set max-parse-time 65535 - not supported in this ACE version"
policy-map multi-match VIPs_HTTPS
loadbalance vip inservice
loadbalance policy HTTPS_L7_POLICY
loadbalance vip icmp-reply active
loadbalance vip advertise active
appl-parameter http advanced-options HTTP_PARAMETER_MAP
ssl-proxy server SSL_PROXY_1
loadbalance policy HTTP_L7_POLICY
You are running into a bug. In release notes for A2(2.x) you see that as open caveats still in version A2(2.2):
CSCtb34660—When a client sends large HTTP POST requests, the ACE advertises the incorrect value for the window size when sending the response page. Workaround: Set the buffer share to 64K bytes unless the ACE starts advertising a window size greater than 64K bytes.
CSCtb34696—When a large POST request is sent to the ACE VIP address with a default window size, the ACE does not acknowledge the bytes and retransmits them in another frame as a result of a misassignment in a previous GET request. Workaround: Set the buffer share to 64K bytes.
You need to configure a connection parameter map an apply it accordingly, which contains the following command:
set tcp buffer-share number
number is defined from 8192 to 262143 (default value is 32768)
I think that will do the trick for you.