70375 - FTP via proxy ignores proxy server mime types

Status: VERIFIED FIXED

(Core Graveyard :: Networking: FTP, defect)

Description

[tenthumbs]

2001022621 trunk build

If using an ftp proxy, mozilla ignores the mime type that the proxy
server provides which causes problems.

Consider the attached html page which is what Squid returns for
<ftp://localhost/pub/>. If I click on the Read.me link, squid returns
these headers:

--->telnet localhost 3128 
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD ftp://localhost/pub/Read.me HTTP/1.1
Host: localhost
Connection: close

HTTP/1.0 200 OK
Server: Squid/2.3.STABLE4
Mime-Version: 1.0
Date: Fri, 23 Feb 2001 18:46:23 GMT
Content-Type: application/x-troff-me
Last-Modified: Fri, 23 Feb 2001 18:43:15 GMT
Age: 174991
X-Cache: HIT from localhost
Proxy-Connection: close

yet mozilla displays it. If it really were a troff document, it would
not be useful to display it.

Clicking on the "frob" link is more interesting. Here squid returns:

--->telnet localhost 3128
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD ftp://localhost/pub/frob HTTP/1.1
Host: localhost
Connection: close

HTTP/1.0 200 OK
Server: Squid/2.3.STABLE4
Mime-Version: 1.0
Date: Wed, 21 Feb 2001 22:23:12 GMT
Content-Type: text/plain
Content-Length: 484520
Last-Modified: Sun, 04 Feb 2001 14:05:26 GMT
Age: 334835
X-Cache: HIT from localhost
Proxy-Connection: close

but mozilla pops up the dialog saying frob has the
application/octet-stream mime type and asks what to do.

Note that squid doesn't know what "frob" is either, so it add two
auxiliary links for the end user. The "view" one always returns
text/plain and the "download" one always returns
application/octet-stream. Too bad for the user. Mozilla insists that it
can only download it.

Mozilla really needs to obey the server.

Comment 1

[tenthumbs]

Attachment: proxy dir listing (html)

Comment 2

[benc]

qa to me.

Comment 3

[Doug Turner (:dougt)]

tenthumbs, can you provide a testcase please.

Comment 4

[tenthumbs]

I'm not sure there is a simple test case because you need a proxy
server. I can describe the procedure.

First you need and ftp URL. I used <ftp://localhost/pub/Read.me> because
a) the file name "Read.me" has given me problems in the past with proxy
servers and b) because I can test it easily on Linux.

You also need a proxy server. I use squid. Because squid comes from the
Unix world, it's default configuration thinks that a .me file extension
is a troff file. It only uses this for services, like ftp, that don't
have their own types. Just in case you don't know, troff is a typesetting
system. It's input files are plain text but are basically a bunch of
macros so they're not particularly readable.

When not using a proxy, mozilla displays the test URL. Mozilla has no
guidance from the server about what the file is so it makes its own
decision. Nothing wrong there. When using the proxy, mozilla still makes
the same decision even though the proxy server returns a content type of
its own.

To see what the proxy server is sending, I point lynx at the URL and get

 env ftp_proxy=http://localhost:3128/ \
    lynx -head -dump ftp://localhost/pub/Read.me

HTTP/1.0 200 OK
Server: Squid/2.3.STABLE4
Mime-Version: 1.0
Date: Tue, 08 May 2001 15:01:13 GMT
Content-Type: application/x-troff-me
Last-Modified: Fri, 23 Feb 2001 18:43:15 GMT
Age: 9877
X-Cache: HIT from localhost
Proxy-Connection: close

The question then becomes why Mozilla does not honor the content-type
header. Obviously, it should since a proxy connection is essentially an
HTTP connection and mozilla obeys content type on real HTTP connections.

That does seem like a minor issue, though. The real issue is that a
proxy server can silently redirect any given URL to any other one. It's
the basis for Junkbuster and its clones. I can do it with squid if I
wish.

The only way the client can know the type of data is to either accept
the proxy server's value or examine the data itself. Mozilla has always
taken the first option. Shouldn't it continue to do so?

Comment 5

[Doug Turner (:dougt)]

does this problem happen with proxied HTTP?

Comment 6

[Doug Turner (:dougt)]

Fixes checked in.  QA please verify.

Comment 7

[[e-mail]]

I've tried to reproduce this problem with my Netscape Proxy Server, but had
problems controlling the "Content-Type:" for my test case. I'd like to know if
the reporter sees this fixed in the trunk.

Comment 8

[tenthumbs]

Fixed in an 0514 nightly build.

I would say this one can be closed.

Comment 9

[benc]

VERIFIED:
If I can get control of this on my proxy, I'll add it to the Proxy+FTP test cases.