RFC 2616 states that "304 Not Modified" responses don't have a body. To quote from http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html "If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields." In addition the responses include a "Connection: keep-alive" header so the socket shouldn't be closed and should be ready for re-use after the http header is received. These link state that NTLM authentication is TCP connection based and authentication is not required after the first HTTP request. http://www.innovation.ch/personal/ronald/ntlm.html http://curl.haxx.se/rfc/ntlm.html#ntlmHttpAuthentication Jeff F> On Wed, Feb 17, 2010 at 4:30 PM, Amos Jeffries wrote: > On Wed, 17 Feb 2010 08:59:27 -0600, Jeff Foster wrote: >> I'm not sure which TCP stream you are referencing in your reply. >> If you are looking at client port 1917; I agree with your response. >> > > There are 7 distinct TCP streams/connections in that trace. > The first 6 display the exact same behavior or persist long enough to do > the login and object fetch, but the object requires closure. > > The 7th does the weird 304 and re-auth required by the server. It also > persists during the entire auth setup sequence, but we never see the end of > the sequence so can't tell if the object kills it as well or not. > > The port does not matter here. Both the server and client and Squid are > all working exactly correctly according to the data they transfer. > > Lets put it this way.... > If the objects being requested were sent by the server with correct > Content-Length headers. The _entire_ page load (all 7 of those connections) > would happen through a single TCP link. > This can be seen working in the 304 response (which has a known 0-byte > length) and its followup request re-using the same ports. > > The reality is that the server is sending out objects that range from 0 > bytes to infinite, without telling Squid how long they are. There is > exactly one way for it to tell Squid the end of any given object and the > start of the next. To completely close the TCP link. > There is exactly one way for Squid to pass that information on. To close > the Squid->client TCP link. > > Cut off the head the body dies. Cut off the body the head dies. Either way > you look at it the client->squid->server pinned linkage dies. > > > NP: I think what you were expecting to see was the client->squid link dies > and 'untie' the squid->server link back to re-use as a normal persistent > connection. Then a new client->squid link to tie it up again later. While > that would normally be the case, these are dying due to the unknown-length > objects, and the server link is the first to go down. > > >> The problem as I see it is the TCP stream for the client port 1919. >> It is using port 37159 on the squid server to the upstream. Then >> in packet 210 the upstream request switches to port 37161. >> >> The trace was run from the initial client request to long after the >> Internet Explorer authentication dialog was displayed. > > All of this happens magically in the background away from the users view, > thus its called 'transparent' authentication. Access to pages being > 'transparent' from the users view. > > > Amos > >> On Wed, Feb 17, 2010 at 1:50 AM, Amos Jeffries wrote: >>> Jeff Foster wrote: >>>> >>> >>> Hi Jeff, >>> >>> Looking at the 3.1 capture I see everything working perfectly as it >>> should >>> be. >>> >>> The connection is held open as expected of persistent connections >>> through >>> the enire auth sequence and beyond. It finishes with an actual page >>> result >>> starting to come back from the final auth credentials. >>> >>> The thing to notice at this point is that the object being fetched has >>> no >>> Content-Length: header and so the connection MUST end with closure to >>> terminate the file. This will prevent it ever being re-used as you >>> expected. >>> NP: all the object replies this server produces seem to have this type >>> of >>> content preventing connection re-use. >>> >>> At the end it is your client machine which sends a RST packet and > aborts >>> the download and closes the connections before the object is complete, >>> its >>> visibly a partial page in the trace. >>> >>> >>> The only odd thing I can see so far is the followup from the >>> http://simon/Styles/forms.css request. Server replies with a 304 >>> redirection >>> (keep alive allows connection re-use :). As expected The client sends > the >>> auth credentials to the new request URL through teh existing > connection. >>> But >>> then the server replies with a brand new auth challenge as if it had >>> never >>> seen the client before. >>> The trace does not continue long enough to follow that, but I would > hope >>> the client re-auths properly and things continue fine. At least until > the >>> next unknown-length object. >>> >>> Amos >>> -- >>> Please be using >>> Current Stable Squid 2.7.STABLE8 or 3.0.STABLE24 >>> Current Beta Squid 3.1.0.16 >>> >
