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
Summary: Publishing difficulties to some free sites (ftp). → Publishing difficulties to 0catch.com
*** This bug has been marked as a duplicate of 138658 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
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?
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.
Summary: Publishing difficulties to 0catch.com → Publishing difficulties to 0catch.com (ftp serialization)
Not a UI problem, reassigning to Kathy
Assignee: cmanske → brade
nominating ISP bug...could affect other ISP's also.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: publish → publish [adt2 rtm]
Target Milestone: --- → mozilla1.0
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).
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
Created attachment 84684 [details] [diff] [review] serialization patch (revision 1) comments? feedback?
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
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?
Created attachment 84802 [details] [diff] [review] partially updated patch (so Charley can help with testing)
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 DSLMichael@aol.com). The ftp serialization issues/keywords/etc. will move over to bug 138662.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → WORKSFORME
Summary: Publishing difficulties to 0catch.com (ftp serialization) → Publishing difficulties to 0catch.com
Whiteboard: publish [adt2 rtm] → publish
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.