Forum Discussion

lmiestc_26212's avatar
Feb 05, 2010

Logging HTTP header that is longer than the maximum allowed

Hi Community,

 

 

Recently after an upgrade of our Portal I started to see occasional entries in the /var/log/ltm about

 

HTTP header (32800) exceeded maximum allowed size of 32768 and that it is for the HTTP Profile.

 

 

I know that it is just to change the maximum allowed header size for the HTTP Profile but I would like to write an I rule that parses the GET request and if the Headersize exceeds the maximum allowed size it should write the header in /var/log/ltm

 

 

As I am not very good on I rules any ideas on how to write this I rule is much appreciated.

 

 

 

//Ed

8 Replies

  • Hi Ed,

    The HTTP profiles have a "Maximum Header Size" option, which specifies the maximum amount of HTTP header data that the system buffers before making a load balancing decision. So generally, this is just a cosmetic issue.

    If you want to find out which request or response header is greater than the max, you can use an iRule. But it will require looping through every header in every request (and/or response) so you should remove the rule as soon as you find the header(s).

     
      Based on http://devcentral.f5.com/wiki/default.aspx/iRules/LogHttpHeaders.html 
      
     when HTTP_REQUEST { 
      
         Loop through each header by name 
        foreach aHeader [HTTP::header names] { 
      
            Check if the length of the header value is greater than 32k 
           if {[string length [HTTP::header value $aHeader]] > 32768}{ 
      
               Log details for the request 
              log local0. "[IP::client_addr]:[TCP::client_port] (UA: [HTTP::header "User-Agent"] -> [HTTP::host][HTTP::uri],\ 
         $aHeader ([string length [HTTP::header value $aHeader]]): [HTTP::header value $aHeader]" 
           } 
        } 
     } 
     

    If this doesn't match any headers, it might be because the long header value is in the response. If that's the case, you could use something like this:

     
     when HTTP_RESPONSE { 
      
         Loop through each header by name 
        foreach aHeader [HTTP::header names] { 
      
            Check if the length of the header value is greater than 32k 
           if {[string length [HTTP::header value $aHeader]] > 32768}{ 
      
               Log details for the response 
              log local0. "[IP::client_addr]:[TCP::client_port]: $aHeader \ 
                 ([string length [HTTP::header value $aHeader]]): [HTTP::header value $aHeader]" 
           } 
        } 
     } 
     

    Note that many request variables aren't available in the HTTP_RESPONSE event. So if you wanted to log the User-Agent header value or other request characteristics, you'd need to save them on every request and then log them in the responses which contain the long header values.

    Aaron
  • Just to follow up on this...

     

     

    After testing in 10.2, it looks like TMM resets the client connection before HTTP_REQUEST is triggered. This is also matches what is stated in SOL8482:

     

     

    Error Message: HTTP header exceeded maximum allowed size of

     

    http://support.f5.com/kb/en-us/solutions/public/8000/400/sol8482.html

     

     

    So it isn't possible to use an iRule to log the long header names in HTTP_REQUEST.

     

     

    If the error happens consistently, you could try to capture a tcpdump to find the long header. Or you could just increase the max header size until you don't see the error anymore.

     

     

    Aaron

     

  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Just to clarify, although I can see how the error message could be interpreted this way, it is referring to the total size of all HTTP headers, not any one specific header. So if you have a request with 10 headers that are each 4k long, you'd still hit the limit. If this header size limit is exceeded, then we stop parsing the headers, and kill the connection (so HTTP_REQUEST is indeed never triggered in this case).

     

     

    If you still want to track down an example request which is triggering this condition, then Aaron's tcpdump suggestion is a good one.
  • Hi Guys,

     

     

    What if I want to create a logging (I know iRules can do this) for client IP and Port when a max header value of http profile has been reached and then blocked?

     

     

    Thanks!

     

  • Hi Raj,

     

     

    As described above in this post, the connection is reset before HTTP_REQUEST is triggered. To capture this in an iRule you'd need to buffer on every TCP connection and look in the TCP payload for the HTTP headers. This wouldn't be very efficient.

     

     

    I suggest using tcpdump to try to trap this. You can use a script like ringdump.pl to capture this:

     

     

    http://devcentral.f5.com/tabid/1082223/aff/31/afv/topic/aft/1172521/afc/1173894/Default.aspx

     

     

    Aaron
  • It seems that this message isn't about the size of one single header, but the size of the full request header, including http command ("GET /... HTTP/1.1") and http headers.

     

     

    It's easy to allow logging something for these requests : just increase "Maximum Header Size" in http profile, but at this point, I don't know if it's possible to access the request header size.

     

     

    Seems that HTTP:header is only about A header and not THE header...

     

  • It seems that this message isn't about the size of one single header, but the size of the full request header, including http command ("GET /... HTTP/1.1") and http headers.

     

     

    Exactly. The HTTP profile setting is the max size for the HTTP headers combined including the request line.

     

     

    It's easy to allow logging something for these requests : just increase "Maximum Header Size" in http profile, but at this point, I don't know if it's possible to access the request header size.

     

     

    Well, it's easy to increase the max headers size, but you can still get requests with a larger header size than you've seen before/configured to be allowed. So it's not so easy to guarantee that you can log the max size you could receive.

     

     

    Aaron