138254 - cannot publish to ISP(sbcglobal.net)

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[sujay]

Robin tried publishing a small test document with an image to her ISP. She tried
using 6.x (branch build ID 2002041617) and Communicator 4.7. Both attempts were
unsuccessful, and doesn't know why.

Using Cute FTP, she can ftp to her publishing site with no problems:

hostname: pages.sbcglobal.net
username: [e-mail]
pw: (her sbc password)
Location to publish to:  http://pages.sbcglobal.net/robinc
Browse URL: http://pages.sbcglobal.net/robinc/

Using CuteFTP, she uploaded a file successfully to this site.

Using both 6.x and Comm 4.7, she could not publish to this site. With 6.x, the
files failed to publish.
When she changed location to publish to as ftp://pages.sbcglobal.net/robinc
(instead of http://), she got "login
incorrect" message. With Comm 4.7, she got a "server error" window saying that
"Server has encountered an
internal error" .

Comment 1

[robinf]

I used info provided at this page to determine my publishing settings:

http://pages.prodigy.net/main/ftp.html

The relevant info begins with "If your ID on SBC Global looks like...". My
username is [e-mail].

Comment 2

[robinf]

Forgot to add...I was able to use these settings in CuteFTP to successfully ftp
to my publishing directory and upload a file that way.

Comment 3

[sujay]

Comments from Charley: 

Your username is your full email address? That makes me suspect that there's a
parsing error in the
network code because it relies on "@" to separate the "username:password" from
the host portion. So the
resulting full URL would be: "http | ftp]
//[e-mail]:[e-mail]/robinc". I
bet it's extracting the username as "robin" instead of the full email address
and thus failing to publish.

Comment 4

[sujay]

Comments from Robin:



When I use an ftp program to get to my publishing site, entering my full email
address works...I'm able to
log in. Here's the response from the server:

220-Welcome to the PI Personal Web Pages Server.
220-
220 pwp01-int FTP server (Version wu-2.4(66) Tue Apr 16 16:41:36 EDT 2002)
ready.
331 Password required for robinc.
230 User ROBINC logged in.  Access restrictions apply.

Comment 5

[robinf]

Just tried publishing with MachV build, using "robinc" as user name. The publish
status dialog comes up, and both files (the html and the gif) fail to publish.

In Comm 4.7, substituted "robinc" for user name. Get alert message "Netscape is
unable to locate the server test.html. Please check the name and try again."
Weird thing is, it's looking for a server named "test.html", when that's the
name of the page I'm trying to publish.

Comment 6

[Charles Manske]

According to the directions, you should be using 
ftp://pages.sbcglobal.net
as the publishing URL (don't include "robinc" subdirectory)
Try that, and use your full email address as the username

Comment 7

[robinf]

Charley, I followed your instructions exactly, and I get "login incorrect" error
after clicking Publish button.

Comment 8

[robinf]

When I try same thing with Comm 4.7, click Publish button and I get "Netscape is
unable to locate the server(no name specified). Please check the name and try
again."

Comment 9

[sujay]

Robin, since you are getting the same error on 4.x
as well as 6.x, these leads me to believe there is something
wrong with authentication or paths on the server. It might
be worthwhile talking to tech support for SBC global. we 
should be able to figure out what the problem is.

Comment 10

[sujay]

Mitch/Doug/Bradley, any idea whats going on here?

Comment 11

[robinf]

Please let me know what I should ask if I call SBC tech support. I can FTP and
browse to my publishing site with no problems, which means I'm not sure what to
ask them.

Comment 12

[michael wendell]

Could this be related to bug 138257?

The problem there is very likely that Composer is escaping the @ sign in the
password.  Since there is an @ sign in the username for this bug description, it
would lead me to believe that the same thing might be happening here.  

Comment 13

[Bradley Baetz (:bbaetz)]

Yeah, this looks similar to the other bug.

Comment 14

[sujay]

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

Comment 15

[sujay]

verified.

Comment 16

[robinf]

Using trunk build ID 2002042510:

I used the following settings:

Publishing URL: ftp://pages.sbcglobal.net/
Browse URL: http://pages.sbcglobal.net/robinc

User name: [e-mail]
Password: (my password)

I was able to login OK, but then this alert displayed:

553. Could not determine cwdir: no such file or directory

The publishing status displayed "some files failed to publish" with X next to
both files (the .html and the .gif).

I also tried entering the browser URL as http://pages.sbcglobal.net/, but got
the same results.

Comment 17

[robinf]

FYI, I can publish this file and image successfully to my internal publishing
site at http://jazz/users/robinf/public/machV/Comet.html

Comment 18

[Charles Manske]

Try leaving the "HTTP address to browse to" blank.
Also try publishing w/o the image.

Comment 19

[robinf]

Using trunk build ID 2002042510:

At home now - get same error as reported in my comment #16 (at work). Now I'll
try Charley's suggestions...

Comment 20

[robinf]

I tried leaving the "HTTP address to browse to" blank, but got same error (553.
Could not determine cwdir: no such file or directory)

Also tried publishing w/o the image but got same error again.

Comment 21

[robinf]

I'm not convinced that this bug is a dupe of bug 138257, since that bug has been
verified fixed and I still can't publish.

Comment 22

[sujay]

REOPEN because 138257 is fixed and yet Robin is still having
problems publishing.

Comment 23

[robinf]

If anyone has suggestions for how I can troubleshoot this bug, please add them
to this bug and I'll address them today. I'll be out of the office next Mon. and
Tues. (4/29-4/30).

Comment 24

[robinf]

Spoke with Charley. I will attach some FTP log files to this bug for debugging
purposes.

Using CUTEFTP, one test he had me do was to append a closing "/" to my ftp host
address and try to log in to my home directory. Using host address
"pages.sbcglobal.net/" I'm unable to log in to my home directory using CUTEFTP.
Using host address "pages.sbcglobal.net" I'm able to sucessfully log in to my
home directory (robinc). More to come soon.

Comment 25

[robinf]

Attachment: ftp log file test 1

Using Build ID 2002042510 trunk

Attaching publishing test 1 ftp log file.

Created a new Composer document called test.html.
Used these settings:
Publishing URL: ftp://pages.sbcglobal.net/
HTTP address to browse to: (left this blank)
Username: [e-mail]
Password: (my password)

Clicked Publish button. Got same error as before:

553. Could not determine cwdir: no such file or directory

Comment 26

[robinf]

Attachment: ftp log for test 1

Creating attachment again (changed attachment type to text)

Comment 27

[robinf]

Attachment: ftp log for publishing test 1

This is the correct attachment to use for test 1 ftp log.

Comment 28

[robinf]

Attachment: ftp log for publishing test 1

Apologies, this latest attachment is the correct one to use for publishing test
1 described in comment #25.

Comment 29

[robinf]

Attachment: ftp log for publishing test 2

Publishing test 2: 

Open existing document in Composer called Comet.html. This document contains
one image file, called comet.gif.

Used same publishing settings as in test 1, and got same error.

I first tried publishing including the image. On second publishing attempt, I
removed the check mark from "include images and other files" and tried to
publish  again, but got same error.

Comment 30

[Charles Manske]

Doug will investigate

Comment 31

[Doug Turner (:dougt)]

Attachment: Fixes stor <filename>

I am not convinced that this is the right thing to do.	The RFC is useless.  I
have tested uploading to sbcglobal.net and a few internal servers and
everything works.  If this patch is accepted, we need to ensure that other
servers didn't regress.

Note that the only change is to ftp uploading.

Comment 32

[Bradley Baetz (:bbaetz)]

This will almost certainly break storing to subdirectories if you log on with a
user whose initial directory isn't /.

Andreas?

Comment 33

[Doug Turner (:dougt)]

we need to cwd to path then...  i guess.

Comment 34

[Bradley Baetz (:bbaetz)]

There was a reason for not dong that which I cna't recall. Andreas probably
knows, though.

I'm more interesting in why this is failing, though - what is in mPath?

Comment 35

[Andreas Otte]

According to the RFCs we need to CWD into each subdirectory separatly, instead
we do it with a single access. This was done in 4.x and also in mozilla,
performance reasons I guess. 

I will look into this, it seems really strange that this is not working as it is. 

Comment 36

[Andreas Otte]

Okay, normally if someone logs into his/her account he/she will end up in the
home directory of that account. That could be for example /home/www/robinf/ and
that should be what PWD should return and be stored in mPwd, while mPath in this
case would be only the filename because the user is in his/her root directory.
Publishing a file like test.html would result in STOR /home/www/robinf/test.html
which (I guess) would work just fine.

The problem seems to me that on this server PWD in a user directory returns /
instead of the real path to the login directory, so we end up trying to write
into the root directory where we probably have no write access.

Dougs patch would break all servers that return the right path on PWD. One
possible solution I guess would be to CWD each segment (as asked by the RFCs)
and remove all the pwd stuff that was used to avoid it. But I would rather fix
the server ...

Comment 37

[benc]

I've been thinking about this aspect of how ftp and file URL's work, because I
think the RFC is poorly written in the context of trying to claim that the URI
is not a path, but not addressing issues of where the URI access should "begin".

In this case, I think the real problem is that when you publish, the URL is not
what you enter:

ftp://server/path/file

it is actually:

ftp://user@server/path/file

Which, to some degree is actually distinct, and could not necessarily be assumed
to have the same URI=path mapping, because users might see the file space via
FTP from different chroots.

Comment 38

[Andreas Otte]

You are right Ben, but I think the ftp-RFC is not poorly written, it says that
the path is always relative to the users home directory unless you force a root
access with %2F/path (or //path which only works in mozilla). The problem arises
every time the users accesspoint and what the system returns as accesspoint via
PWD are different, because we try to generate an absolute path out of that
information.

Comment 39

[Charles Manske]

I tried the patch by DougT for "Fixes stor" and it didn't seem to solve the
problem for this ISP.

Comment 40

[benc]

By "poorly written", I mean that it should have spelled out the implications of
this "if you mean root, you better encode / in your URL" and "not all roots are
equal". 

A better example I thought of is simply this:

most anonymous ftp's that are configured correctly use chroot to an anonymous
ftp home/root. So:

ftp://server/%2F/file (-> ftp://anonymous@server/%2F/file)

almost is never the same thing as:

file://user@server/%2F/file

because their rooted file systems are completely different.

Comment 41

[Andreas Otte]

Okay, but then the real problem is the current implementation, which previously
had no concept of relative paths at all (always asumed an absolute path) and now
always wants to make the path absolute based on the information provided by PWD
and the URL. Maybe we really have to go the hard CWD way, but that looks like a
major rewrite to me.

Comment 42

[Doug Turner (:dougt)]

Attachment: better fix

mPath is the wrong file path to be used as a parameter to STOR. 

This patch makes uploads relative to the CWD of the login.  If you want to have
something uploaded outside this CWD, a url with double root seperators may be
used, such as ftp://[e-mail]//usr/local/foo.  In most cases, being
relative to login CWD is the right thing.

Comment 43

[Darin Fisher]

Comment on attachment 81721 [details] [diff] [review]
better fix

you probably want to unescape nsIURL::filePath in case there are non-ASCII
characters in the file path.

Comment 44

[Kathleen :Brade]

nit--move this down (to right before it's used):
  +    nsCAutoString storStr;

Comment 45

[Charles Manske]

This patch works well for me. I tested publishing:
1. Local file to the root directory, with an without putting in
"http://pages.sbcglobal.net/robinc/" in the "Browse to address" input in 
Publish dialog settings.
2. Local file published to a "testsubdir" subdirectory (created with another 
program)
2. Local file with an image published to the "testsubdir"

Comment 46

[Doug Turner (:dougt)]

Attachment: unescapes stor param.

Comment 47

[Darin Fisher]

Comment on attachment 81742 [details] [diff] [review]
unescapes stor param.

sr=darin

Comment 48

[Kathleen :Brade]

Comment on attachment 81742 [details] [diff] [review]
unescapes stor param.

r=brade but please move this down:
+    nsCAutoString storStr;
so it's above:
+    rv = aURL->GetFilePath(storStr);

Comment 49

[Andreas Otte]

If this works well we should be thinking about moving this to the other commands
like RETR, ... but that needs a lot of testing. I will try this and look through
the old bugs on the topic.

Comment 50

[Doug Turner (:dougt)]

Marking FIXED since the patch got checked into the trunk

Adding adt1.0.0 to get ADT's attention for 1.0 branch checkin

Comment 51

[Doug Turner (:dougt)]

Andreas, that is exactly what I was thinking.  Do you want to open a new bug up
to track this investigation?

Comment 52

[sujay]

Andreas, please open a new bug and let us know the bug number here...thanks!

Comment 53

[Andreas Otte]

already happened, see bug 141440

Comment 54

[scottputterman]

adding adt1.0.0+.  Please check this in to the branch as soon as possible after
getting drivers approval. Then add the fixed1.0.0 keyword.

Comment 55

[Kathleen :Brade]

has anyone request driver-approval to land this fix?

Comment 56

[robinf]

Using trunk Build ID 2002050204, this is fixed. I can now publish an .html
document with or without an image in it to my publishing site at sbcglobal. Thanks!!

Comment 57

[Doug Turner (:dougt)]

yes.  I waited up till about 1am and did not recieve any response.  

Comment 58

[sujay]

verified per Robin's comments.

Comment 59

[Charles Manske]

Note: another problem when publishing to sbcglobal.net is the creation of
multiple site entries because of the "@" in the username. This is covered by
bug 141819

Comment 60

[Scott Collins]

Comment on attachment 81742 [details] [diff] [review]
unescapes stor param.

a=scc (on behalf of drivers) for checkin to the Mozilla1.0 branch

Comment 61

[Doug Turner (:dougt)]

Checking in nsFtpConnectionThread.cpp;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v  <-- 
nsFtpConnectionThread.cpp
new revision: 1.237.2.3; previous revision: 1.237.2.2
done

Comment 62

[robinf]

Using branch build: 20002-05-06-08-1.0.0 (Build ID 2002050606) on Win 32,
Windows 2000 professional, I can publish successfully to sbcglobal.net, so this
bug is verified fixed in the branch.

However, during the publishing process for an .html file and an .gif file, the
status message first displays "Publishing failed!" even though a check mark is
then displayed next to the .html file. After publishing is complete for the .gif
file, then the status message changes to "Publishing Completed" and both files
display check marks and are in fact published when I verify by looking at my
site at http://pages.sbcglobal.net/robinc.

Sujay, should I file a separate bug on the erroneous "Publishing Failed" message
that appears during publishing?

Comment 63

[sujay]

Robin, that issue you mention is already covered in this bug which
is fixed on the trunk, but not on the branch:

http://bugzilla.mozilla.org/show_bug.cgi?id=138040

Comment 64

[sujay]

verified per Robin's comments.