Stop sending Proxy-Connection

RESOLVED FIXED in mozilla18

Status

()

Core
Networking: HTTP
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: Mark Nottingham, Assigned: mcmanus)

Tracking

({dev-doc-needed})

unspecified
mozilla18
dev-doc-needed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-au) AppleWebKit/531.22.7 (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7
Build Identifier: 

Mozilla should stop sending the Proxy-Connection header when a HTTP proxy is configured.

This header is non-standard, doesn't work well (because proxies will forward it), and isn't implemented by modern proxies.

Furthermore, removing it will have the worst effect of not negotiating persistent connections with very old proxies; it will not cause interoperability issues.

Reproducible: Always
(Reporter)

Comment 1

7 years ago
A bit more.

The worst case scenario here is if a HTTP/1.0 proxy that:
 - does not understand persistent connections to servers (i.e., only close delimitation), AND
 - doesn't understand and therefore forwards Connection

will hang and wait for close, because it unknowingly sends Connection: keep-alive to a HTTP/1.0 server.

However, I note that Safari already sends

  Connection: keep-alive
  Proxy-Connection: keep-alive

in their requests when a proxy is configured, so it appears that this very unlikely configuration isn't seen in practice today.

Comment 2

6 years ago
Tracing a connection with Firebug does not show the presence of Proxy-Connection in the request headers being sent from my copy of Firefox 3.6.13 when it's set to use a proxy server. Nor is the header seen in Wireshark, which I think is pretty conclusive. If Firefox is sending this header in any circumstances, they aren't normal circumstances that I've been able to reproduce.
Quite odd.  nsHttpHandler::AddStandardRequestHeaders clearly adds a Proxy-Connection header (with comments as to why it's doing it, note), when useProxy is true.
And note that so does nsHttpConnection::SetupSSLProxyConnect.

Comment 5

6 years ago
What proxy were you connecting to? Specifically, is it HTTP/1.0 or 1.1?
(Assignee)

Updated

5 years ago
Assignee: nobody → mcmanus
(Assignee)

Comment 6

5 years ago
Created attachment 658140 [details] [diff] [review]
patch 0

mark is right.
Attachment #658140 - Flags: review?(jduell.mcbugs)
Attachment #658140 - Flags: review?(jduell.mcbugs) → review+
(Assignee)

Comment 7

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/d28039477b6d
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
https://hg.mozilla.org/mozilla-central/rev/d28039477b6d
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18

Updated

4 years ago
Keywords: dev-doc-needed
(Assignee)

Updated

4 years ago
Depends on: 828236
(Assignee)

Comment 9

4 years ago
in bug 828236 we've got a case of failed NTLM auth on a CONNECT method against a squid/2.6.STABLE9.. there are other reports of 2.7 failure too.

this would probably be a problem with end host NTLM too when using the proxy, but that's going to be pretty rare.

the "worst case" of losing the persistent connection breaks the damn stateful ntlm.
You need to log in before you can comment on or make changes to this bug.