Hello,

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??

Thank you,

Laura

Hi Laura,

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.

With regards,

Ajay Kumar

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.

Laura

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??

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.

with regards,

Ajay Kumar

Hi Ajay,

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

  length-exceed continue

and second time to:

parameter-map type http HTTP-PARAM-MAP

  set content-maxparse-length 65535

  length-exceed continue

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??

Laura

I would like to keep this question open..

"

And how is this related to the Firefox browser, why other browser don't have this problem??

"

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

  persistence-rebalance

  set header-maxparse-length 65535

  length-exceed continue

What is the obvious downside of using this ?

- Benedikt

Hi Ajay,

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.

Best regards,

Hans

Hi Hans,

Good to know that it was helpful.

regards,

Ajay Kumar

Hi

i was trying to resolve this problem adding http parameter to my configuration. But the problem still exist.

ACE version:

Version A2(2.0) [build 3.0(0)A2(2.0)]

ACE config:

parameter-map type http HTTP_PARAMETER_MAP

  persistence-rebalance

  set header-maxparse-length 65535

  set content-maxparse-length 65535

  length-exceed continue

"set max-parse-time 65535 - not supported in this ACE version"

policy-map multi-match VIPs_HTTPS

  class L4VIPCLASS_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

  class L4VIPCLASS_HTTP

    loadbalance vip inservice

    loadbalance policy HTTP_L7_POLICY

    appl-parameter http advanced-options HTTP_PARAMETER_MAP

Thank you

Hi Tomasz,

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.

Best regards,
Hans