Sake_Blok
Mar 28, 2006Nimbostratus
Workaround for invalid 304 content-length
Hi,
In a migration towards the BigIP, I encounter a problem with http-304 responses. In the http-header there is a "Content-Length" header with a value greater than 0. The http-rfc clearly states that a 304 MUST NOT have a body, therefore a content-length is also invalid. The effect of this content-length-header is that the BigIP is waiting for the amount of data that the header is announcing. Only after the server terminates the connection the BigIP will send the 304-response back to the client. This is an unacceptable delay.
The problem will be fixed on the http-server, but in the meantime I would like to build an iRule as a temporary workaround.
I have tried many things already and only the following iRule is working:
when HTTP_RESPONSE {
if {([HTTP::status] == 304) && [HTTP::header exists Content-Length]} {
log local0. "304 found with content-length"
HTTP::respond 304
HTTP::disable
}
}
But the HTTP::disable disables HTTP-parsing for subsequent http-requests in the TCP-session (OneConnect is enabled also on this virtual). If I do a 'HTTP::header replace "Content-Length" "0"' the header is altered towards the client, but I guess there is still an internal variable that is holding the content-length value, so the BigIP will still try to collect that amount of data from the http-response and this will result in the timeout on the server and the delay towards the client.
Is there a way to change this internal variable? Or is there another way the stop the BigIP from waiting on this (nonexisting) content?
Cheers, Sake