Open
Bug 729496
Opened 13 years ago
Updated 2 years ago
SPNEGO uses an extra round trip on every connection compared to IE9
Categories
(Core :: Networking, defect, P5)
Tracking
()
UNCONFIRMED
People
(Reporter: dholth, Unassigned)
References
Details
(Whiteboard: [necko-would-take][ntlm])
Attachments
(1 file)
2.45 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243
Steps to reproduce:
The attached Python program runs on a Kerberized (linux) machine, takes a realm name EXAMPLE.ORG and a port number and does SPNEGO authentication on incoming connections.
Actual results:
Firefox (and Chrome) re-negotiate SPNEGO every single time, so there is a 401 and then a 200 on every page load. Internet Explorer remembers the Authenticate header for the session and sends a different, updated one on every request, saving one round trip per page load.
Expected results:
Firefox should remember the SPNEGO Authenticate header for the duration of the session.
I wonder if the strange NTLM per-connection authentication has been incorrectly re-implemented for SPNEGO?
![]() |
||
Updated•11 years ago
|
Component: Untriaged → Networking
Product: Firefox → Core
Comment 1•11 years ago
|
||
We are experiencing the same behavior, each request gets a 401 response first. Can anybody confirm that this is the right behavior? It's mainly relevant for Intranets where SPNEGO is generally the first choice for SSO.
Comment 2•9 years ago
|
||
It is not the client which has to remember but the server has to store the GSS name of the client in the HTTP connection (persistent authentication). The server may do this.
Comment 4•9 years ago
|
||
(In reply to Michael Osipov from comment #2)
> It is not the client which has to remember but the server has to store the
> GSS name of the client in the HTTP connection (persistent authentication).
> The server may do this.
You seem to be saying that the problem is the server, not the client. However, if this is true why does the desired behavior of only one round-trip instead of two happen with IE, but not with Firefox? Seems the client behavior matters.
Comment 5•9 years ago
|
||
(In reply to Ryan Slominski from comment #4)
> (In reply to Michael Osipov from comment #2)
> > It is not the client which has to remember but the server has to store the
> > GSS name of the client in the HTTP connection (persistent authentication).
> > The server may do this.
>
> You seem to be saying that the problem is the server, not the client.
> However, if this is true why does the desired behavior of only one
> round-trip instead of two happen with IE, but not with Firefox? Seems the
> client behavior matters.
I did not say that there is a problem at all. It is solely the server's decision to persist the authentication information or not. The client simply reacts on a 401, no more no less. I have several authentication modules (in Java and C) which are either connection-legged or request-legged and both of them work fine with Firefox, Chrome, IE, curl.
As far as the Python script is concerned, it does request-legged authentication. Perfectly fine with Kerberos.
Unless I haven't seen a Fiddler capture or Wireshark pcap of the problem, I cannot confirm any erractic behavior here.
Btw, the IE will always authenticate when the server requests it to. I have used this for years from IE6 to IE11.
Updated•9 years ago
|
Whiteboard: [necko-would-take][ntlm]
Comment 6•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•