Forum Discussion

dave_11182's avatar
dave_11182
Icon for Nimbostratus rankNimbostratus
Mar 25, 2009

Bug with HTTP::path and HTTP requests that use the absolute URL in the Request-Line

I have section code that works like the following (simplified for example)

 

 

when HTTP_REQUEST {

 

log local0. "Path is: [HTTP::path]"

 

}

 

 

if i received a request as follows:

 

 

GET /examplepath HTTP/1.1

 

Host: www.example.org

 

 

the i-rule correctly logs "/examplepath". However if a request is received as follows:

 

 

GET http://www.example.org/examplepath HTTP/1.1

 

 

the i-rule logs "http://www.example.org/examplepath". According to the http spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.htmlsec5) this is valid request form.

 

 

The wiki states that HTTP::path only "returns or sets the path part of the HTTP request," so I'm assuming this is a bug. I'm currently using BIG-IP 9.1.2. Is this a known issue resolved in a newer version?

 

 

Thanks for any help or direction,

 

 

Dave

 

 

2 Replies

  • Hi Dave,

     

     

    In theory HTTP::path parses the path of the URI. In actuality, I think it returns what ever is in the URI up to the first question mark. Yes, RFC2616 states you can use an absolute URL in the request line, but almost no clients do this. I think the most common scenario this is seen is with HTTP proxies.

     

     

    Here is a post where we discussed some options for handling this in an iRule:

     

     

    http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&tpage=1&view=topic&postid=1141211444 (Click here)

     

     

    So should LTM check every request to see if the request line is absolute or relative? Maybe? If you think the current behavior is broken/could be improved, you could open a case with F5 through their support group.

     

     

    Aaron
  • Thanks for the link, I will take a peak at the solution. I agree that almost no clients do this, but at the very least the documentation is misleading and should be updated to accurately describe what the function actually does. Many iRule developers are not experts in HTTP protocol minutiae and I imagine this could lead to lead to hard to track down bugs for others as well. That said i think the general usefulness of the function is diminished by the current behavior in this scenario.

     

     

    I've gone ahead and opened a bug with F5 but will investigate using the solution in the link as a stop gap short term solution.

     

     

    thanks,

     

     

    Dave