138662 - Publishing difficulties to prohosting.com (ftp serialization)

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[TucsonTester1]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc1) Gecko/20020419
Netscape6/6.2.1+
BuildID:    2002041906

Successive publishing attempts fail when publishing with Netscape Composer.



Reproducible: Always
Steps to Reproduce:
Account: <username>
Password: psswrd
FTP Server: snow.prohosting.com
HTTP Url: http://snow.prohosting.com/<username>

1.Launch new/blank Composer window.
2.Add content(do not include an image) and publish to ftp site.
3.Add more content(no image)and attempt to publish.



Actual Results:  The first publish attempt works fine and successive attempts
will also publish, as long as there is not an image inserted in the page.

If an image is inserted and the page is published, an Alert 421 opens stating
"Sorry can only be logged in once." 

Netscape must be closed and reopened to allow publishing.

Expected Results:  Netscape should allow successive uploads.  In comparison,
cuteftp allows for multiple uploads, downloads, etc. to this site.

Similar to bug 138658, 138659

Comment 1

[michael wendell]

Updating summary.

Comment 2

[Charles Manske]

This is an unfortunate consequence of the fact that we start multiple FTP channels
when publishing page + images. It would be solved by "serializing" the FTP 
uploads (only do one at a time.) Brade is working on this.

Comment 3

[sujay]

nominating because this could affect other ISPs also.

Comment 4

[sujay]

is this a DUP of bug 138659 ?

Comment 5

[Kathleen :Brade]

carry over whiteboard/keywords from bug 138659

Comment 6

[Kathleen :Brade]

These are the things I'd like others to test (I already have tested these) (and
QA to verify):
 Browser:
   * save file with no images (HTML Complete)
   * save file with no images (html only)
   * save file with images (HTML Complete)
   * save file with images (html only)
   * save frameset with images (HTML Complete)
 Composer:
   * save file with no images
   * publish file with no images (ftp, http, https)
   * save file with images (from server to local)
   * save existing local file over itself (with images)
   * publish file with 1 image (ftp, http, https)
   * publish file with more than 1 image (ftp, http, https)
   * publish file with images into a subdir (ftp, http, https)
   * publish file that contains links/images already on server

Check that all links and image locations are correct (html source).

note: I did test with an ftp server configured for only one login.  I confirmed
the code was working correctly (serializing) by looking at server logs and
client packet observations.

Latest patch coming...

Comment 7

[Kathleen :Brade]

Attachment: patch

comments? reviews? feedback?

Comment 8

[Charles Manske]

This rocks! I've worked with this patch for 3 days now and after testing a number
of successful and error scenarios;  the nsIWebProgressListener
status notification is much more dependable. This fix really makes it easier
for me to provide better error reporting and publish status monitoring.
I can publish pages with large number of images with now problems now. It solves
lots of problems with servers that have limited connections. Lets get this 
checked into trunk ASAP!

Comment 9

[Adam Lock]

r=adamlock

Comment 10

[Alec Flett]

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

sr=alecf

Comment 11

[Kathleen :Brade]

fix checked into trunk

Comment 12

[Kathleen :Brade]

oops; I forgot to check in the Composer flag check...
I'll land that when the tree reopens

Comment 13

[sujay]

If this bug is fixed, please mark RESOLVED-FIXED.

Comment 14

[Kathleen :Brade]

setting the serialization flag in Composer is now checked into the trunk; sorry
I didn't get it sooner (as intended)

Comment 15

[michael wendell]

Here is what I am seeing with the 06-04 trunk build:

Browser:
   * save file with no images (HTML Complete) -  Works fine.
   * save file with no images (html only)  -  Relative links stay relative, and
are not converted to absolute (is this working as designed?)
   * save file with images (HTML Complete)  -  Works fine.
   * save file with images (html only)  -  Relative links stay relative, and are
not converted to absolute (is this working as designed?)
   * save frameset with images (HTML Complete)  -  Works fine.
 Composer:
   * save file with no images  -  Works fine
   * publish file with no images (ftp, http, https)  -  Works fine with ftp and
http, I do not have https to test.
   * save file with images (from server to local)  -  Works fine, except that
the relative links stay relative (is this working as designed?)
   * save existing local file over itself (with images)  -  Works fine.
   * publish file with 1 image (ftp, http, https)  -  Works fine with ftp and
http, I do not have https to test.
   * publish file with more than 1 image (ftp, http, https)  -  Works fine with
ftp and http, I do not have https to test.
   * publish file with images into a subdir (ftp, http, https)  -  Works fine
with ftp and http, I do not have https to test.
   * publish file that contains links/images already on server  -  Works fine
with ftp and http, I do not have https to test.

Near as I can tell, this can be verified.  I am not verifying this though,
because I do not have an HTTPS server to publish to, and I am not sure how the
relative links are supposed to be handled when saving a file as HTML only (see
above).  

Comment 16

[Kathleen :Brade]

In the browser, saving the html only does not touch the links.

BenC--do you have any internal https servers configured with http put enabled
that DSLMichael could test with?

Comment 17

[benc]

I don't at this time. If your QA needs a server like this, they can run that
testing requirement up the management chain.

Comment 18

[Kathleen :Brade]

Michael--please verify without https.  That will need to be covered in a
separate bug (since it's not clear to me that it worked before this patch was
checked in on the trunk).

Comment 19

[michael wendell]

Verified.

Comment 20

[scottputterman]

adding adt1.0.1+.  Please get drivers approval before checking into the branch.

Comment 21

[Kathleen :Brade]

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

driver approval requested on Wednesday

marking has-review for adamlock since maybe that is blocking getting approval?

Comment 22

[chris hofmann]

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

a=chofmann for 1.0.1  add fixed1.0.1 and remove mozilla1.0.1+ from keywords
after checking in.

Comment 23

[Kathleen :Brade]

this fix was checked into the 1.0.1 tree on Saturday
Shrir--please verify

Comment 24

[Charles Manske]

Shri: A really good test is to publish a file with a lot of images.
When you do, watch the Publish Progress dialog:
The first file in the list is the .html file. It will show the "busy" icon 
during the entire publishing session. Note that we are NOT actually uploading 
that file at this time (I just put it first so the HTML file isn't lost among
all the image files).
But after that, you should see each image file listed first with the busy icon,
and then the green checkmark icon if successful, or the red X if not, immediately 
before the next image is added to the list. Thus you are seeing one image uploaded
at a time, proving that they are now serialized rather than trying to publish
> 1 at a time like we used to.

Comment 25

[Terri Preston]

When trying to verify this bug, I'm having trouble connecting to this server,
anyone else have this problem?

Comment 26

[Kathleen :Brade]

Terri--does it work today?  Can you reach the server in the browser?

Comment 27

[Terri Preston]

I am still unable to get to this site, michael wendell is also unable to reach 
this site, does anyone happen to know a different site this could be tested 
on??????

Comment 28

[Charles Manske]

Serialized publishing has worked on 3 FTP sites that I have tested. 
The fix in general is good. Individual sites may have other problems.

Comment 29

[Terri Preston]

Could not verify on prohosting.com but did verify on several other sites, Win XP
branch build 2002061408, Linux branch build 2002061414 and Mac OS X branch build
2002061405