Closed Bug 138662 Opened 19 years ago Closed 19 years ago
Publishing difficulties to prohosting
.com (ftp serialization)
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
Summary: Publishing difficulties to some free sites (ftp). → Publishing difficulties to prohosting.com
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.
Assignee: cmanske → brade
nominating because this could affect other ISPs also.
is this a DUP of bug 138659 ?
carry over whiteboard/keywords from bug 138659
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...
Severity: minor → critical
Target Milestone: --- → mozilla1.0
comments? reviews? feedback?
Whiteboard: publishing [adt2 rtm] → publishing [adt2 rtm] custrtm-
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 on attachment 84935 [details] [diff] [review] patch sr=alecf
Attachment #84935 - Flags: superreview+
fix checked into trunk
Target Milestone: mozilla1.0 → mozilla1.0.1
oops; I forgot to check in the Composer flag check... I'll land that when the tree reopens
If this bug is fixed, please mark RESOLVED-FIXED.
setting the serialization flag in Composer is now checked into the trunk; sorry I didn't get it sooner (as intended)
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
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).
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?
I don't at this time. If your QA needs a server like this, they can run that testing requirement up the management chain.
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).
Status: RESOLVED → VERIFIED
adding adt1.0.1+. Please get drivers approval before checking into the branch.
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?
Attachment #84935 - Flags: review+
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.
Attachment #84935 - Flags: approval+
this fix was checked into the 1.0.1 tree on Saturday Shrir--please verify
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.
When trying to verify this bug, I'm having trouble connecting to this server, anyone else have this problem?
Terri--does it work today? Can you reach the server in the browser?
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??????
Serialized publishing has worked on 3 FTP sites that I have tested. The fix in general is good. Individual sites may have other problems.
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
You need to log in before you can comment on or make changes to this bug.