117263 - Wrong "Host" HTTP header in install through proxy

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Olivier Mengué]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122106

After experimenting problems with download through a proxy I traced the HTTP
request sent by the windows installer-stub to install Mozilla 0.9.7.

I found out that the "Host" HTTP header has always the value of the proxy host
with HTTP download instead .

This occurs only with HTTP download. No problem with FTP download through the proxy.

Reproducible: Always
Steps to Reproduce:
Set a proxy host/port in the installer.

I traced the HTTP requests with a custom TCP proxy between the installer and a
Netscape Proxy 3.5.

Example:
Proxy host : 192.168.0.1
Proxy port : 8080
The download URL is http://ftp.mozilla.org/...

Actual Results:  The "Host" points to the proxy server.
In the exemple:
Host: 192.168.0.1

Expected Results:  The "Host" header should point to the host of the URL where
is the file to download.
In the example:
Host: ftp.mozilla.org

The bug is here :
http://lxr.mozilla.org/mozilla/source/xpinstall/wizard/libxpnet/src/nsHTTPConn.cpp#282
The host should be extracted from the mProxiedURL, as for ftp:// URLs, few lines
above.

By the way, I found the nsHTTPConn API quite strange : calling SetProxyInfo with
the URL to download, and the proxy username/password was not obvious. I had
first expected that the URL parameter of SetProxyInfo was the host/port of the
proxy, not the final host.

Comment 1

[Olivier Mengué]

The bug is here :
http://lxr.mozilla.org/mozilla/source/xpinstall/wizard/libxpnet/src/nsHTTPConn.cpp#282
The host should be extracted from the mProxiedURL, as for ftp:// URLs, (code to
reproduce is just few lines above).

I'm sorry, I haven't a build environment to make/test a patch.

By the way, I found the nsHTTPConn API quite strange : calling SetProxyInfo with
the URL to download, and the proxy username/password was not obvious. I had
first expected that the URL parameter of SetProxyInfo was the host/port of the
proxy, not the final host.

Comment 2

[Boris Zbarsky [:bzbarsky]]

confirming, especially since the exact problem has been pointed out!

Comment 3

[Grace Bush]

taking all proxy related bugs

Comment 4

[Olivier Mengué]

Still in Mozilla 0.9.9 Net installer.

Added in CC endico, 0.9.9 release notes author, as the bug doesn't appear there.

THE CONSEQUENCE OF THIS BUG IS THAT IT IS NOT POSSIBLE TO DOWNLOAD Mozilla
THROUGH Netscape Proxy 3.5 (and probably throug any HTTP proxy) USING THE
Mozilla Net Installer !!!

Comment 5

[Syd Logan]

adt2 per adt traige

Comment 6

[Olivier Mengué]

Still in Mozilla 1.0RC1.

This is a blocking bug with the "Network installer" through a proxy !!!!

No information about the true cause of download problem is reported to the user,
because it is a Mozilla bug. So the user don't know what to do. Personnally I
tried  about 10 times before giving up and tracing the HTTP request as specified
in the original bug report.

The only workaround is to download and use the full installer instead of the
light one.

Please, fix this bug for Mozilla 1.0.

Comment 7

[Olivier Mengué]

Adding mozilla1.0 to raise visibility of this bug.

Comment 8

[Syd Logan]

-->dprice

Comment 9

[dprice (gone)]

I am able to use proxy to download and install the mozilla nightly build from
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest-1.0.0/mozilla-win32-installer.exe
I can't get to 192.168.0.1 so I tested with a different server.  Could that be
the problem?  Please retest and let me know.

Comment 10

[dprice (gone)]

duh, used http for download instead of ftp.  I can reproduce it now.

Comment 11

[dprice (gone)]

Attachment: patch

Comment 12

[Daniel Veditz [:dveditz]]

Comment on attachment 84408 [details] [diff] [review]
patch

r=dveditz

Comment 13

[benc]

Can you provide a trace or logs from the proxy server?

My Netscape Proxy Server has never rejected requests based on any of the various
"Host: line is incorrect bugs" I've worked on...

Comment 14

[dprice (gone)]

From your email address I'm guessing you're inside the firewall.  I was able to
use the server carbuncle port 8080 to reproduce this.  

Comment 15

[Samir Gehani]

Comment on attachment 84408 [details] [diff] [review]
patch

r=sgehani

Comment 16

[Scott MacGregor]

Comment on attachment 84408 [details] [diff] [review]
patch

sr=mscott

Comment 17

[benc]

(I'm the administrator of that proxy...)

I understand now. Can someone clarify this aspect in the summary:

This only happens with one of the two modes right (ftp probably...).

FTP and HTTP proxy both use an HTTP connection (they are actually URL proxy of
an ftp:// URL or http:// URL inside HTTP). 

I know that one mode seems to have failed a lot for me lately (can't tell b/c I
have to quit to run the installer to see...)

Comment 18

[Olivier Mengué]

Attachment: Patch

patch.
- code factorised from dprice patch to handle common operations for proxied FTP
and HTTP urls.
- corrects a small bug: variables host and path where not initialized to NULL.

I'm very sorry: this code may not compile as I haven't a build environment to
compile/test this patch.

Comment 19

[dprice (gone)]

Thanks for the patch :) It looks much cleaner that what I did.  I'll test with
it and get it landed.

Comment 20

[dprice (gone)]

Attachment: patch 3

fixes a compile error and changes the indent style to match the rest of the
file.

Comment 21

[Olivier Mengué]

The patch is ok.

By the way, I'm distributing my original patch (patch 2) under the NPL/GPL/LGPL
"triple license".

Comment 22

[Samir Gehani]

Comment on attachment 85006 [details] [diff] [review]
patch 3

r=sgehani

Please add a comment mentioning that the port is not overridden if specified
when calling ParseURL().

Comment 23

[Daniel Veditz [:dveditz]]

Olivier: since you're patch is a Modification of the original file you can't
really change the license on the file (which currently is MPL). Are you OK with
us using it as MPL only? mozilla.org is working toward converting the entire
tree, so eventually it'll be switched.

Comment 24

[Daniel Veditz [:dveditz]]

Comment on attachment 85006 [details] [diff] [review]
patch 3

sr=dveditz, I think the license question is irrelevant here

Comment 25

[Olivier Mengué]

dveditz:
According to http://www.mozilla.org/MPL/relicensing-faq.html, the tree is going
to be relicensed to the three licences MPL/GPL/LGPL.

According to http://www.mozilla.org/MPL/license-policy.html :
<BLOCKQUOTE>
The following license is acceptable for both new Mozilla source files and
modifications to existing source files, for any directory in the Mozilla source
tree (except those specified below):

* MPL/GPL/LGPL triple license
</BLOCKQUOTE>

The header of this file (nsHTTPConn.cpp) says the code is currently only
copyrighted by Netscape.
If you force me to release it under only the MPL license, I may one day be a
blocker to relicensing just because I'm not available or dead or....

I don't want to block the relicensing effort. So this is why I proposed to
release the patch under the three licenses. I'm not an expert in licensing
terms, but I just want to not block software from being released under the LGPL/GPL.

So isn't it the good time for Netscape to relicense the file under the three
license just before accepting my patch ?

Or maybe this comments written by myself, telling that I accept MPL/GPL/LGPL
relicensing, will be enough when relicensing time will come for this source file.

Comment 26

[Daniel Veditz [:dveditz]]

I believe your statement in this bug will be sufficient.

Comment 27

[dprice (gone)]

on the trunk

Comment 28

[Grace Bush]

using trunk builds for 5/31 and installing both commercial and  mozilla apps, 
using carbuncle, 8080 for proxy
Windows and Linux give successful downloads and installs.
on Mac OS 9.2, the commercial installer does nothing, the resume button keeps 
becoming enabled and I had to force/quit.
the Mozilla installer did download and install but the UI was all messed up.
The first three lines were empty for most of the download- and the progress 
showed x kb of 0kb for each component downloaded.  After each component 
downloaded, I had to press resume.  At one point the first line said:
downloading: validating quality feedback agent for a long time.

bottom line: verified on trunk for Linux and Windows but not Mac

Comment 29

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 85006 [details] [diff] [review]
patch 3

please check into the 1.0.1 branch ASAP. once landed remove the 
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword

Comment 30

[Syd Logan]

grace, did you try Mac without using proxy, but with the same installer?  How
did it work?

Comment 31

[Grace Bush]

Yes, I did other installs with same Installer - trunk for 5/31- no problems

Comment 32

[dprice (gone)]

I filed bug 149505 to handle the issues raised for the mac.  I believe they are
separate from the problem solved in this bug.  

Comment 33

[Jaime Rodriguez, Jr.]

adt1.0.1+ (on the ADT's behalf) approval to checkin to the 1.0 branch. pls check
this in asap, then add the "fixed1.0.1" keyword.

Comment 34

[Grace Bush]

marking verified on trunk for Linux and Windows

Comment 35

[Grace Bush]

Mozilla- Linux and Windows branch and trunk builds 

Comment 36

[Myk Melez [:myk] [@mykmelez]]

*** Bug 183410 has been marked as a duplicate of this bug. ***