ACE & HTTP Header size on A2(3.2a)

[BGPatemyHamster]

We have a problem with an application whereby, from certain countries, we are seeing session ID errors being displayed by the web client used to interact with an application.

Firstly, as a bit of background, we found that by increasing the

set header-maxparse-length <bytes>

command within the context for the application of the ACE module that supports all users for this app in all countries to 8192 bytes that this solved the issue for some countries, but for others the problem persisted.

Focusing on one country which continued to have problems, as a test, extra information added by the proxy into the HTTP header was removed (by Proxy reconfiguration) that would normally have been sent, this was:-

X-BlueCoat-Via: xxxxxxxxxx

X-Forwarded-For: x.x.x.x

Via: 1.1 BAYEC-BC-20

Connection: close

X-BlueCoat-Via: xxxxxxxxxxxxx

This actually solved the problem in that the users no longer see Session ID errors, but now on occasion they are getting errors appearing telling them that the client is “UNABLE TO SETUP DATA CONNECTION”.

We are thinking of upping the value of the header-maxparse-length again but we are unsure what to set it too as we do not know the size of it by the time it hits the ACE. Having had a look around we see a lot of users just changing the set header-maxparse-length value to 65535.  We assume this will simply increase the processing required for the packet and the memory used by the ACE, however we do not know what an appropriate value may be here.

In addition, I note that we can allow the packets to proceed, as opposed to being dropped by using

length-exceed continue

But we are unsure if this would cause problems if the ACE cannot identify which server to send the packets too.

Finally, there is another command,

set content-maxparse-length

The default for this again is 4096 bytes, however, I must admit im not sure what the ACE is defining as “content”. The body of the HTTP requests can go as high as 20000 bytes that I have seen should this value be adjusted to accommodate?

I should also add that we do see max parselen errors increasing but we cannot pin it down to this specific app.

[sivaksiv]

Hi,

In general the ACE stops parsing once it finds what it needs, when it hits the end of the header, or when it hits the max-header-parse-length. So if there's a match in the first 4096 bytes of the header the connection should be load balanced to the proper sfarm.

The difference when "length-exceed continue" is used", the connection will be using the class-default sfarm unless a match is found on the fisrt 4096 bytes of the header. Without "length exceed continue" the connection is dropped unless a match is found in the first 4096 bytes.

This should not cause a major performance issue, if you only have a few connections that may reach that limit on occasion.

If you see the parselen errors incrementing then its likely you should increase the header-parselen to suit the requirement. A trace for a particular connection that fails should explain the size of a request.

-

Siva