TJ wrote:
Right now Juniper are claiming the issue that brought this to the
surface (the bug linked to in my original post) is a problem with the
implementation of TCP_DEFER_ACCEPT.
My position so far is that the Juniper DX OS is not following the HTTP
standard because it doesn't send a request with the connection, and as I
read the end of section 1.4 of RFC2616, an HTTP connection should be
accompanied by a request.
Can anyone confirm my interpretation or provide references to firm it
up, or refute it?
You can think of TCP_DEFER_ACCEPT as an implicit application close()
after a certain timeout, when not receiving a request. All HTTP servers
do this anyway (though I think technically they're supposed to send a
408 Request Timeout error it seems many do not). It's a very valid
question for Juniper as to why their box is failing to fill requests
when its back-end connection has gone away, instead of re-establishing
the connection and filling the request.
-John
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
