Proxy: 'Proxy-Connection:' sent to HTTPS server over CONNECT

VERIFIED WORKSFORME

Status

()

Core
Networking: HTTP
VERIFIED WORKSFORME
16 years ago
15 years ago

People

(Reporter: Bazsi, Assigned: Darin Fisher)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020206
BuildID:    Mozilla 0.9.8 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8)
Gecko/20020206

If a non-transparent SSL proxy is used (with the CONNECT method),
the request sent to the webserver looks like a proxy request with a 
full URL instead of a simple filename + Host field.

Reproducible: Always
Steps to Reproduce:
1. use a proxy server for SSL connections
2. connect to a webserver using SSL
3. the webserver receives a proxy request wrapped within SSL

Actual Results:  the webserver receives a proxy request wrapped within SSL

Expected Results:  use a simple non-proxy request.

Comment 1

16 years ago
please, reopen if you still see the problem with a current build

*** This bug has been marked as a duplicate of 127671 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 2

16 years ago
I think this maybe distinct.

You are saying that your request (sent via connect:) says:

GET https://hostname.com/URI

when it should say:

GET /URI
Host: hostname.com

Can you provide more information on how you are gathering this data and give
some log snippets?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(Reporter)

Comment 3

16 years ago
Ops, while gathering more information I found it was not caused by the URI
thing I described in my original bugreport.

Our firewall software rejects proxy like requests in HTTP if not explicitly
allowed, that's why I noticed the whole thing. 

The decision whether a request is meant for a proxy (ie. a proxy request) is
made based on the following criteria:
* if it contains a proxy-connection header it is a proxy request
* if it contains a connection header it is _not_ a proxy request
* if it neither contains a proxy-connection or connection, it is decided based
on the value
  of the URI. If it starts with '/' it is a server request otherwise a proxy
request.

I assumed the third condition was true, but while gathering more info, it
turned out that the 'Proxy-Connection: ' header was present in my request as
the log below shows:

Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): Request
details; command='GET', url='/newbie/_top', version='HTTP/1.1'
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): prefilter
request header; hdr='Host: xxx.com'
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): prefilter
request header; hdr='User-Agent: Mozilla/5.0 (X11; U; Linux i68
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): prefilter
request header; hdr='Accept: text/xml,application/xml,applicati
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): prefilter
request header; hdr='Accept-Language: en-us'
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): prefilter
request header; hdr='Accept-Encoding: gzip, deflate, compress;q
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): prefilter
request header; hdr='Accept-Charset: ISO-8859-1, utf-8;q=0.66, 
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): prefilter
request header; hdr='Keep-Alive: 300'
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): prefilter
request header; hdr='Proxy-Connection: keep-alive'
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): prefilter
request header; hdr='Cookie: SessionID=65f8089d4d49f67eea2a10ee
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): prefilter
request header; hdr='Pragma: no-cache'
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): prefilter
request header; hdr='Cache-Control: no-cache'
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): processing
request and headers;
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): proxy
requests not permitted in transparent mode.
Apr 18 10:25:12 fw inter[12749]: (zorp@xxx/inter_https_dmz:0/http): exiting
keep-alive loop;

So it seems to be the same as the bug it was merged to.

Comment 4

16 years ago
That bug is sort of not going anywhere, so lets assume this is different.

Is your setup:

client -> SSL Proxy -> xxx.com (https server)

Is the info you are providing from the host "xxx.com"? (When you said it was a
firewall, that confused me.)
(Reporter)

Comment 5

16 years ago
There's a firewall sitting in front-of xxx.com decrypting and analyzing HTTPS
traffic as it goes. The log is from the firewall's log.

The problem is caused by the 'Proxy-Connection' header, which should've been
'Connection'.
status of this?

Comment 7

15 years ago
Bazsi: There is a good chance that this was fixed w/ other problems for Mozilla
1.1. Please update.
Assignee: new-network-bugs → darin
Component: Networking → Networking: HTTP
QA Contact: benc → httpqa
Summary: Proxy request is sent if a non-transparent proxy is used for SSL. → Proxy: 'Proxy-Connection:' sent to HTTPS server over CONNECT

Comment 8

15 years ago
No response from the reporter. I'm going to resolve INVALID because nobody got
to the point of reproducing it. Bazsi, if you think this is still an issue, and
you can help somebody reproduce it, please feel free to reopen the report.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago15 years ago
Resolution: --- → INVALID

Comment 9

15 years ago
qa to me.

REOPEN -> this certainly isn't INVALID, since there is some pretty useful data here.

At best, it's a WFM, which should become a testcase. This is hard to setup, but
was something I was going to get to.

Darin, if you need to clear some query, assign it to me if necessary.
Status: RESOLVED → UNCONFIRMED
QA Contact: httpqa → benc
Resolution: INVALID → ---
(Assignee)

Comment 10

15 years ago
this sounds like a duplicate of a bug that was fixed around the time this one
was filed.  for a little while we had a regression like this.  a quick
inspection of the code indicates that this should be fixed now.  marking WORKSFORME.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → WORKSFORME

Comment 11

15 years ago
VERIFIED:
wfm.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.