Forum Discussion

Patrik_Jonsson's avatar
Patrik_Jonsson
Icon for MVP rankMVP
Apr 13, 2014

HSL logging logs strange URI

Hi!

Wrote a logging iRule to log cache response headers with HSL. It works fine generally but some uris are pretty strange.

Here is the rule:

when HTTP_REQUEST priority 999 {
    set host [string tolower [HTTP::host]]
    set uri [HTTP::uri]

    set hsl [HSL::open -proto UDP -pool syslog-514_pool]
}

when HTTP_RESPONSE {

   if { [HTTP::header exists "Cache-Control"] } {
        set CacheControl [HTTP::header "Cache-Control"]
    } else { 
        set CacheControl " "
    }

    if { [HTTP::header exists "Expires"] } {
        set Expires [HTTP::header "Expires"]
    } else { 
        set Expires " "
    }

    HSL::send $hsl "[string map [list "\t \t" "\t-\t"]\
        "<165>\t\
        $Expires\t\
        $CacheControl\t\
        $uri\t\
        $host\t\
        "]\n"
}

Here is one of the lines that looks strange (note that this particular response did not have an Expires header):

Date                   Log Level       Source IP       Expires      Max-Age                              URI                      Host
2014-04-11 08:08:36Local4.Notice10.0.0.1max-age=60, must-revalidate, publichttps://ourwebsite.com/directory/service.svc?query=stringourwebsite.com

We can't seen the strange URI's in the IIS logs. Could it be that the BigIP rejects it because the request is malformed? I am out of ideas.

/Patrik

application delivery
devops
hsl
iRules
LTM
  • Patrik_Jonsson's avatar
    Patrik_Jonsson
    Icon for MVP rankMVP
    Apr 14, 2014

    An update:

     

    Turns out IIS logs the strange URI in a different way and that it's actually "real". Found it after digging manually in the log files.

     

    Case closed. :)

     

    /Patrik

     

  • Patrik_Jonsson's avatar
    Patrik_Jonsson
    Icon for MVP rankMVP
    Apr 24, 2014

    Another update, apparently IIS actually handles and processes URI's with the protocol + fqdn + uri as URI while only logging the URI. I have no idea what the entries that I found came from though so that needs more digging.

    If someone else encounters this it seems like some proxies enters the URI that way when handling HTTP 1.1 connections. My source is not 100% reliable, but upon checking the top incoming public IPs it sure looks like they're proxies.

    These seems to go straight through the LB without being cached so we had to rewrite the URI before caching it.

    Here it is in case someone else needs it.

    when HTTP_REQUEST {

    set uri [string tolower [HTTP::uri]]

    if { $uri starts_with "https://" } {
        scan $uri {https://%[^/]%s} host uri
        HTTP::uri $uri
    }
}

    /Patrik