Re: [squid-users] NTLM Authentication and Connection Pinning problem

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