Forum Discussion
Ed_Hammond_2611
Nimbostratus
NimbostratusHTTP 304 Status - How to drop content
We have a server that is appending 20 bytes of content to a 304 status response in violation of RFC. Fixing the server is a real challenge as it is functionally stable, so we are forced to mask the error in the proxy. Our proxy previous to F5 did the "nice thing" and did not send along any content, but the F5 sends it along causing various problems in client-side proxies and firewalls.
We have tried to use the HTTP::payload command, but it returns as if there is no content. To my way of thinking, this is clearly a bug in the payload command; either there is content and HTTP::payload should provide access to it, or the F5 should not forward any content.
BIGIP-LTM Support suggested we post here to find the answer. We need the lightest and simplest method to remove the content *only* on 304 responses. (This is a very active site, so the solution needs to be as efficient as possible.)
We've tried STREAM::expression and studied the TCP::payload command methods. The stream worked in development pretty well, but had unpleasant side effects when placed under load. I'm not sure how will http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&forumid=5&postid=7287 will work on a pretty active site with oneconnect in operation.
This would be simple if the HTTP::payload command worked as you would expect regardless of the status code. Either that or if payload is smart enough to know a 304 is not supposed to have content, the F5 should not pass along any content.
What would people suggest?
Anyone solved such a problem before?
Thanks in advance.
3 Replies
- The_BhattmanMy first time encountering this type of issue on the post.
That being said how about trying the followingwhen HTTP_RESPONSE { If { [HTTP::status]="304" } { http::respond 304 content "" } }
Keep in mind I am making several assumptions but hopefully this generates a solution
CB 
Ed_Hammond_2611We have released this code into production with positive feeback from our customers that were affected.
The problem the customers were having was with Symantec and Kasperski firewalls where the TCP connection would stall when the extra bytes were seen in the response. The client side TCP connection would not respond to the browser, causing the page to "hang" until the TCP timeout occured and the browser opened a new connection. This used connection capacity on the firewall and terrible response time on the client side, but the F5 side looked fine and dandy.
There are two change requests out to fix the extra header material in HTTP::respond (CR99706 & CR64228). Hopefully what development will do in the respond call is to scan the headers provided and only fill in the gaps that are absolutely needed per RFC2616. In the case of the above, nothing extra would be needed.
We'll see how well development and fix the HTTP::respond command.
P.S. Support dropped the request to fix the HTTP::payload command so that it works consistently across all status codes. That's a real shame as it has been a problem for years- Thanks a ton for the update. I look forward to hearing how this gets addressed. If I hear anything I'll make sure to update here as well.
Colin
