Jeff Foster wrote:
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."
Please re-read what I said in the third sentence under "Lets put it this
way...."
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.
Please re-read all of what I said under "Lets put it this way...."
If you still don't understand answer this:
Telling the remote end to keep a link alive, then closing the link
yourself has what effect?
That is exactly what the server is doing.
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
Thats what I described as "weird". The server is not obeying that. It
challenged for every new object requested within link #7 in your trace.
Amos
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
--
Please be using
Current Stable Squid 2.7.STABLE8 or 3.0.STABLE24
Current Beta Squid 3.1.0.16
