Forum Discussion

strongarm_46960's avatar
strongarm_46960
Icon for Nimbostratus rankNimbostratus
Feb 27, 2009

304 Status responses bug discovered

Today I reported a new bug in BIG-IP ASM Version 9.4.6 401.0, for RAM Cache and 304 Status responses for requests without IMS headers. I thought this should have been fixed under CR62309, its returned again.

 

 

This bug manifest itself by the LTM sending a HTTP 304 Status Response code to any browsers without a If-Modified-Since request header, which inturn affects all my LTM cached objects, thus affects my user experience, not rendering js, css, images etc.

 

 

I have a written an iRule as a workaround to change the 304 response code to 200, any suggestion on improving the iRule would be invaluable until F5 releases a fix.

 

 

 

when HTTP_REQUEST {

 

if {[HTTP::header exists "If-Modified-Since"] } {

 

set ims 1

 

 

if { $::debug>=1 } { log local0. "Bingo found an If-Modified-Since from User" }

 

} elseif { ![HTTP::header exists "If-Modified-Since"] } {

 

set ims 0

 

}

 

}

 

 

when HTTP_REQUEST_SEND {

 

TCP::collect 12

 

}

 

when SERVER_DATA {

 

if { [findstr [TCP::payload 12] "304"] == "304" and [info exists ims] and $ims ==0} {

 

TCP::payload replace 9 3 "200"

 

}

 

}

 

 

 

Thanks

 

Jeremy.
application delivery
dev
devops
iRules

7 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Feb 27, 2009
    Does the iRule work? If so, I think it looks okay. I don't fully understand the bug though. If the server sends a 304 it can't send cotent. So why do you want to rewrite the response to a 200? Wouldn't the client get a 200 with no data and assume the object did exist but has 0 length?

    If you use that rule, you could streamline it slightly by removing the check if the IMS header does not exist: 

     
 when HTTP_REQUEST { 
    if {[HTTP::header exists "If-Modified-Since"] } { 
       set ims 1 
       if { $::debug>=1 } { log local0. "Bingo found an If-Modified-Since from User" } 
    } else { 
       set ims 0  
    }  
 }  
 when HTTP_REQUEST_SEND {  
    TCP::collect 12  
 } 
 when SERVER_DATA {  
    if { [findstr [TCP::payload 12] "304"] == "304" and [info exists ims] and $ims ==0} {  
       TCP::payload replace 9 3 "200"  
    }  
 }

    Aaron
  • strongarm_46960's avatar
    strongarm_46960
    Icon for Nimbostratus rankNimbostratus
    Feb 27, 2009
    You are right the server does not send content with the 304, are you suggesting I replace the status 200 with a 204 instead, you might be on to something there.

     

     

    Thanks
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Feb 27, 2009
    Hi Jeremy,

     

     

    Could you explain what the issue is, what should happen and what you're thinking of doing with an iRule to make it happen?

     

     

    Thanks,

     

    Aaron
  • strongarm_46960's avatar
    strongarm_46960
    Icon for Nimbostratus rankNimbostratus
    Feb 27, 2009
    This bug manifest itself by the LTM sending a HTTP 304 Status Response code to any browsers. Okay, Ordinarily there’s nothing wrong with the LTM sending HTTP 304 Status Response code to a browser, however, sending it without receiving a browser If-Modified-Since request header breaks the RFC 2616, and therein lies the bug.

     

     

    In most cases during this 304 bug transaction, a If-Modified-Since was generated from the LTM to the backend, and was captured in the debugging within , consequently, a 304 Response was seen in Rule debug-304 .

     

     

    Somehow the if-Modified-Since sent from the LTM to the backend, which generated a 304 response, also triggers a 304 sent to the user aswell, which then produces the bug.

     

     

    This bug affects all browsers, thus all LTM cached objects which include all images, JavaScript & css. This system flaw affects user experience.

     

     

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Feb 27, 2009
    Actually SOL7472 and SOL7484 both mention CR62309. The latter SOL has a suggested workaround, which kind of makes sense considering the request needs to be passed back to the origin server and not be answered from cache: 

     
 when HTTP_REQUEST { 
    if { [HTTP::header exists If-Modified-Since] } { 
       CACHE::disable 
    } 
 }

    By the way, what did F5 Support suggest as a workaround?

    Aaron