138659 - Publishing difficulties to 0catch.com

Status: VERIFIED WORKSFORME

(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:
0catch.com
Account: <username>.0catch.com
Password: psswrd
FTP Server: www.0catch.com 
HTTP Url:  <username>.0catch.com

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, again an Alert 421 opens
stating "Sorry there are already X users from <ip address> logged on. Try again
in 10 minutes." 

After ~5 minute wait - Alert "450 Socket read from client timed out."
but still unable to publish.

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.

Similar to bug 138658

Comment 1

[michael wendell]

Updating summary.

Comment 2

[Charles Manske]

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

Comment 3

[Kathleen :Brade]

I don't understand how this is a duplicate of bug 138658.
The bug here (as I understand it) is that the publishing code makes more than 1
connection to the ftp server and the server isn't happy about that (it limits
logins to 1 per ip address).  This may be a duplicate of another bug but I don't
think it's related to bug 138658.

Reopen for reconsideration.

Comment 4

[Charles Manske]

It seemed like both this and bug 138658 are related to the need to serialize 
FTP uploads so we don't open multiple connections. I thought they were close 
enough to dup, sorry!
They are both dependent on that bug (which I can't seem to find!), right?

Comment 5

[Kathleen :Brade]

It's not clear to me that bug 138658 is about ftp serialization.  This bug is. 
If you don't want to fix it, you can reassign it to me.

Comment 6

[Charles Manske]

Not a UI problem, reassigning to Kathy

Comment 7

[sujay]

nominating ISP bug...could affect other ISP's also.

Comment 8

[Kathleen :Brade]

I have a patch that allowed me to successfully publish to 0catch.com (file plus
3 images).  Most of the changes are in web persist and those are mostly due to
moving code into a new method.  I'd like help with testing.

DSL Michael--can you confirm that the problem still exists (I tested OS9 trunk
with my patch) without this fix?

These are the things I'd like to test before landing (please note any additions!):
 Browser:
   * save file with no images (HTML Complete)
   * save file with no images (html only)
   * save file with images (HTML Complete)
   * 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).

Comment 9

[Kathleen :Brade]

Attachment: serialization patch (revision 1)

comments? feedback?

Comment 10

[michael wendell]

Here is what I am seeing on Win 2k with the 05-22 trunk build:

1. Launch Composer, add some text, and publish to valid 0catch.com site - works fine
2. Add an image to the page, and republish to the same site - works fine
3. Add some more text to the page and republish to the same site - the html file
publishes fine, but the image that was published on step 2 does not appear to
publish, the progress bar just spins.
4  Cancel the publish, add some more text to the page, and attempt to republish
again - this time the original html file publishes, and an html file with the
image's filename is published, but the image itself continues to hang without
publishing.


The issue I am seeing is covered by bug 145337, and I never receive any alerts
about too many open connections.

So it appears to me that the original problem described here is fixed . . .
unless the original problem is now causing bug 145337

Comment 11

[Charles Manske]

I tested a page with 30 images and it uploaded all images perfectly with this
patch (see bug 144261).
Kathy: I noticed that this fix will still result in 2 simultaneous connections:
one for HTML page and one for the the serialized images. Should we also wait
for the page to finish upload before starting the image connections?

Comment 12

[Kathleen :Brade]

Attachment: partially updated patch (so Charley can help with testing)

Comment 13

[Kathleen :Brade]

The observation is comment 11 is incorrect/misleading.  The information
displayed in the progress dialog includes the html file which is not serializing
at the same time the image is.

Since this bug is currently working (with the exception of bug 145337) I am
going to resolve this bug as WORKSFORME (per [e-mail]).

The ftp serialization issues/keywords/etc. will move over to bug 138662.

Comment 14

[sujay]

verified.

Comment 15

[sujay]

verified.