146166 - Improper file/properties display when dates are sent in some local formats

Status: RESOLVED FIXED

(Core Graveyard :: Networking: FTP, defect)

Description

[Miguel Covas]

Whenever you use Mozilla to connect to a HP-UX ftp server, you can't obtain a
proper display of the files, and their properties.
You get for each file an icon and the sequence representing file permissions and
type. Both the icon and the file permissions are hiperlinked to a file in the
same directory whose name equals the file permission sequence.

This behavior happens when connecting to HP-UX 10.20 and 11.0 and having set or
not a proxy for ftp

Comment 1

[Bradley Baetz (:bbaetz)]

Can you give me the URL to an HPUX server which is publically accessible?

Comment 2

[Miguel Covas]

After some effort I've been able to setup a public ftp server on a spare HP
machine. You can reach that machine at 195.235.207.59 with user: ftptesto and
password: dqdsesto

The machine will be available for a couple of weeks. After that we have to put
it at work.

Although I tried hard, I've been unable to get rid of the proxy ftp the firewall
sets from the inside network. However, accessing to an external ISP from a
modem, then returning back to our public network I could reproduce the behavior.

Hope this helps

Comment 3

[Greg K.]

That server returns "500 command not permitted through gateway."

Comment 4

[Miguel Covas]

This behavior happens only with browsers. Character mode ftp clients work
fine.The ftp server is in the DMZ of a firewall which denies pasive mode access:
Jun 20 12:45:48 pandora.bancoval.es ftp-gw[1343]: permit
host=nodnsquery/217.124.42.67 connect to 195.235.207.59 ID=1343136
Jun 20 12:45:49 pandora.bancoval.es ftp-gw[1343]: log
host=nodnsquery/217.124.42.67 operation USER ftptesto ID=1343136
Jun 20 12:45:57 pandora.bancoval.es ftp-gw[1343]: deny
host=nodnsquery/217.124.42.67 operation PASV ID=1343136
Jun 20 12:46:01 pandora.bancoval.es ftp-gw[1343]: exit
host=nodnsquery/217.124.42.67 cmds=0 in=0 out=0 user=unauth duration=13
mode=Proxy ID=1343136

But you can access the ftp server with a character mode ftp client. (Can you?)
If you can access in that way, what is happening with the browser?
If there is no way to test the ftp server I'll try to put it in the "outback"..

Comment 5

[Greg K.]

Miguel, are you saying this isn't a Mozilla-only problem, that it happens with
any web browser?

Comment 6

[Miguel Covas]

Greg:
the strange behavior happens only with Mozilla or with Netscape.
I noticed odd behaviors with HP-UX ftp servers and Netscape 4.7 early in 1999
both in Mac 9.x and Win 95/98 as we migrated from HP-UX 9.x to 10.20.
Now is HP-UX 11 and it happens the same. The behavior in 4.7 was slightly
different. There were no gifs, just the "-r-xr-xr-x" ...
IE for Win works, you can navigate directories and download a file.
Omniweb for Mac OSX works.
Linux Conqueror works...

Comment 7

[Greg K.]

In my testing, Mozilla, IE, and iCab all failed to connect to your server.
OmniWeb was able to, as was my regular FTP client, Interarchy.

Most browsers use only passive FTP mode, and that appears to be the problem
here. Examining Interarchy's transcript of the session (which I'll attach
hereon), after the PASV command fails, it attempts PORT, which succeeds. OmniWeb
probably implements PORT, also.

Bug 465 is all about getting PORT going in Mozilla, so I'm going to mark this a
duplicate of that.

*** This bug has been marked as a duplicate of 465 ***

Comment 8

[Greg K.]

Attachment: Interarchy transcript of FTP session

Comment 9

[Miguel Covas]

I agree in that there is some problem with Mozilla going through a firewall, but
I think that this problem is masking the one stated in the description of this bug:
i.e. it is unable to represent a directory list on a HTML page with hyperlinks
to navigate directories and download files.

Do you think worth the effort to put a HP machine outside the firewall?

Comment 10

[Miguel Covas]

I found the source of the improper behavior. HP-UX systems can be localized to
adapt output formats to different languages. Although normal users seldom use
that feature, inetd is started with the LANG variable set and when ftpd lists a
directory the creation date of the files is shown in the local format.
The command "ls -l texto" will display
-rw-rw-rw-   1 mcovas     sag            976 Aug 29  1996 texto
while if I set LANG to "es_ES.iso88591" I'll get
-rw-rw-rw-   1 mcovas     sag            976 29 Ago  1996 texto

quite the same as if I use a ftp client to connect to the machine and list the
directory:
-rw-rw-rw-   1 mcovas     sag            976 29 Ago  1996 texto

As Mozilla ftp client parses that line (In order to get the week day, I think)
it gets embroided with the file name and permissions.
If I start inetd with an unset LANG or LANG=C, then I use Mozilla to connect to
the ftp server IT WORKS!!!
For the time being I'm going to start inetd on every machine without LANG set,
but I think that the parser deserves a second thought

Comment 11

[benc]

REOPEN: not a PORT problem.
I've tried to improve the summary. If anyone can improve it further, please do so.

Comment 12

[Bradley Baetz (:bbaetz)]

I have no time to work on mozilla at the moment, so dougt is taking over FTP

open ftp bugs -> him

Comment 13

[Doug Turner (:dougt)]

Hoping this will be fixed when we have a new list parser.

Comment 14

[Doug Turner (:dougt)]

Fixed via 95590

Comment 15

[Greg K.]

Shouldn't this then be duped to bug 95590 rather than being resolved fixed?