Last Comment Bug 321999 - HTTP waits for response to determine keep-alive state
: HTTP waits for response to determine keep-alive state
Status: RESOLVED FIXED
: fixed1.8.1
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: All All
: -- minor (vote)
: mozilla1.9alpha1
Assigned To: Darin Fisher
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-31 08:20 PST by Darin Fisher
Modified: 2006-03-12 19:04 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 patch (1.75 KB, patch)
2006-02-03 15:25 PST, Darin Fisher
cbiesinger: review+
bzbarsky: superreview+
bzbarsky: approval‑branch‑1.8.1+
Details | Diff | Review

Description Darin Fisher 2005-12-31 08:20:14 PST
HTTP waits for response to determine keep-alive state

Instead, we should look at the request headers to determine if the request can result in a "keep-alive" response.  If not, then we should immediately treat the request's connection as non-persistent.

Doing so would give XMLHttpRequest users the additional ability to set "Connection: close" as a request header to signal to the HTTP layer that the "AJAX" request is known to take a long time to complete and thereby avoid situations where the web app appears hung waiting on the HTTP layer to give it a connection to use.
Comment 1 Darin Fisher 2006-02-03 15:25:56 PST
Created attachment 210648 [details] [diff] [review]
v1 patch
Comment 2 Darin Fisher 2006-02-03 15:28:50 PST
My one (small) concern with this patch is that specifying "connection: close" on a request that requires NTLM (or SPNEGO) authentication is going to break badly.  This patch doesn't really change that except that it makes the browser enforce the closure instead of relying on the server to do so.  This patch might break something if a server was previously ignoring "connection: close" headers during a NTLM exchange.  It would be really bad for a server to ignore those headers, but that doesn't mean that someone isn't doing it.

It'll be interesting to see if that problem comes up in the field.
Comment 3 Boris Zbarsky [:bz] (Out June 25-July 6) 2006-02-03 15:29:14 PST
So why strcasestr instead of strcasecmp or something?
Comment 4 Darin Fisher 2006-02-03 15:41:16 PST
Because, they could also have "Connection: close, foo", which means that the "foo" header should not be forwarded by a proxy server.  I need to write a HasToken function instead and use that in many other places throughout the HTTP code.  Using PL_strcasestr is just par for the course and clearly suboptimal.
Comment 5 Boris Zbarsky [:bz] (Out June 25-July 6) 2006-02-03 15:50:58 PST
Comment on attachment 210648 [details] [diff] [review]
v1 patch

OK.  sr=bzbarsky, but let's get a followup filed on HasToken?
Comment 6 Darin Fisher 2006-02-03 15:56:57 PST
fixed-on-trunk
Comment 7 Darin Fisher 2006-02-08 09:40:45 PST
fixed1.8.1

Note You need to log in before you can comment on or make changes to this bug.