Closed Bug 138662 Opened 19 years ago Closed 19 years ago

Publishing difficulties to prohosting.com (ftp serialization)

Categories

(SeaMonkey :: Composer, defect)

defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0.1

People

(Reporter: TucsonTester1, Assigned: Brade)

References

Details

(Whiteboard: publishing [adt2 rtm] custrtm-)

Attachments

(1 file)

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
Updating summary.
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.
Keywords: nsbeta1
Whiteboard: publishing
is this a DUP of bug 138659 ?
carry over whiteboard/keywords from bug 138659
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: nsbeta1nsbeta1+
OS: Windows 98 → All
Hardware: PC → All
Summary: Publishing difficulties to prohosting.com → Publishing difficulties to prohosting.com (ftp serialization)
Whiteboard: publishing → publishing [adt2 rtm]
Blocks: 144261
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
Attached patch patchSplinter Review
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!


r=adamlock
Comment on attachment 84935 [details] [diff] [review]
patch

sr=alecf
Attachment #84935 - Flags: superreview+
fix checked into trunk
Keywords: adt1.0.1
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).
Keywords: mozilla1.0.1
Verified.
Status: RESOLVED → VERIFIED
adding adt1.0.1+.  Please get drivers approval before checking into the branch.
Keywords: adt1.0.1adt1.0.1+
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
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.