Closed Bug 643352 Opened 13 years ago Closed 13 years ago

Keep-Alive header syntax invalid


(Core :: Networking: HTTP, defect)

Not set





(Reporter: mnot, Assigned: mcmanus)


(Blocks 1 open bug)


(Keywords: dev-doc-complete)


(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-au) AppleWebKit/533.20.25 (KHTML, like Gecko) Version/5.0.4 Safari/533.20.27
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv: Gecko/20101203 Firefox/3.6.13

FireFox sends a Keep-Alive request header in the following form:
  Keep-Alive: 115

However, Keep-Alive is defined by RFC2068 here:
as having the following syntax:

  Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param
  keepalive-param = param-name "=" value

I.e., the syntax is invalid.

Apache currently generates the correct syntax (e.g., Keep-Alive: timeout=120).

While it isn't the end of the world that this is invalid (because AFAICT this header isn't consumed by much software), the variance between Apache and FireFox is being used as an argument for minting Yet Another Header, which is unfortunate (esp. since it would waste Yet More Bytes). See:

Note also that the IETF HTTPbis WG has an open issue about re-defining Keep-Alive:
If Mozilla has input, it would (as always) be welcome.

Reproducible: Always

Steps to Reproduce:
1. Send a persistent request
2. Note the request headers (e.g., with tcpflow)
3. Observe a Keep-Alive header
Actual Results:  
Invalid syntax

Expected Results:  
Valid syntax
Awesome.  A bug dating back to 2001...

This is pretty trivial to change as desired; see

Patrick, Jason, what's the behavior we actually want here?
Ever confirmed: true
(In reply to comment #1)

> Patrick, Jason, what's the behavior we actually want here?

If we're going to make a change, we should probably just go with the straight Connection: keep-alive version without a separate keep-alive request header. That would match chrome and ie too.

We don't do a very good job of honoring our 115 second number anyhow.. anytime we have hit out default global 30 connection limit and then need another one (which happens a lot!) we start closing idle persistent connections before that timer is expired.

Of course, we ought to raise that number from 30 because idle connections have value at very little cost to the client, but that's a different bug.

Mark, fwiw, we do parse the response Keep-Alive header and use that to set our idle timeout target (which as I mention, we often don't make it to). I can't recall off the top of my head whether that is MIN(client,server) or just taking the server value.

I can't get really excited about this whole area of inquiry - robustness requires that this all be event based instead of time based anyhow. I've never really seen much advantage in either side sending a time interval. If our header is malformed we should just stop sending it.
If servers and proxies actually ignore the Keep-Alive header (or even just ignore our broken version), then I agree we should stop sending it.  Want to write a patch?  ;)
(In reply to comment #3)
>  Want to
> write a patch?  ;)

Assignee: nobody → mcmanus
Attachment #520681 - Flags: review?(bzbarsky)
Attachment #520681 - Flags: review?(bzbarsky) → review+
Agreed that you shouldn't send it, esp. if it's inaccurate and if you're reasonably confident people don't use it. No need to emit the valid form unless there are real use cases.
Closed: 13 years ago
Resolution: --- → FIXED
Backed out on suspicion of causing tp4 regression:
Resolution: FIXED → ---
this is cleared of being the tp4 regression (it was 628561).. ready to push
Pushed to cedar:
Flags: in-testsuite?
Whiteboard: fixed-in-cedar
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-cedar
Target Milestone: --- → mozilla2.2
Version: unspecified → Trunk
Turns out we didn't have that header documented anywhere although it was mentioned in passing in a few places in this article:

I've cleared it out of there now.

This change is also now mentioned on Firefox 5 for developers, and on
You need to log in before you can comment on or make changes to this bug.