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.

qa to me.

tenthumbs, can you provide a testcase please.

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?

does this problem happen with proxied HTTP?

Fixes checked in. QA please verify.

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.

Fixed in an 0514 nightly build. I would say this one can be closed.

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