136802 - publish problem w/ images >8K when no content-length header specified

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, defect)

Description

[John Andrews]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020410
BuildID:    2002041016

when publishing a page that includes an image that is pulled from another site,
such as http://banners.wunderground.com/banner/default/US/IA/Iowa_City.gif for
example, composer give a publish failed error, while attempting to upload the
image to the server, then changed the image location link to point to the site
being published to.

Reproducible: Always
Steps to Reproduce:
1.create a composer doc that includes an image stored on another website
2.attempt to publish to your server
3.

Actual Results:  composer errored out attempting to publish this image to MY
website, then published the page while changing the img src in the webpage to
http://aattic.inav.net/Iowa_City.gif 

Expected Results:  when the img src in a web page points to other then the
user's own  website should have left the img src intact i.e.
http://banners.wunderground.com/banner/default/US/IA/Iowa_City.gif

Comment 1

[sujay]

--> brade

Comment 2

[Vadim Berezniker]

Just tested this with linux trunk 2002041218 with a local FTP account and I also
get an error. 
It tells me "550 /home/vadim/Iowa_City.gif: No such file or directory"

Comment 3

[Kathleen :Brade]

resolve as invalid
If you check "include images and other files" then all of your images will move
to the publishing server.

The "fix" is to uncheck the box so no images or related files will be published
(only the html file will be published).

Comment 4

[sujay]

verified..REOPEN if anyone disagrees.

Comment 5

[Vadim Berezniker]

The point is that the image does not get published along with the html ...
instead you get an error saying it's not found.

Comment 6

[sujay]

Vadim REOPEN if you feel this should be reopened....

Comment 7

[Vadim Berezniker]

If the behaviour is as brade mentions, then the image should be properly
uploaded to the publishing location.
This is what actually happens. 
index.html is published to publish/index.html
composer tries SIZE publish/Iowa_City.gif -> No such file
composer tries MDTM publish/Iowa_City.gif -> No such file
composer tries to download publish/Iowa_City.gif -> No such file
composer tries to change directory to publish/Iowa_City.gif -> No such file
composer gives up

If the behaviour is as you described, shouldn't have composer tried uploading
the image if it was not found on the publish site?

Comment 8

[John Andrews]

Perhaps what's needed here is what the old 4.X Netscape Composer had.. a
checkmark option under image properties  to "Leave image at original location".
It appears that the "URL is relative to page location" option is intended to be
the same thing.. but it that's the case, it doesn't appear to be working right.  

Comment 9

[Kathleen :Brade]

Vadim Berezniker--Unfortunately I don't see this problem with any images other
than the one you are using.  I tried:  http://mozilla.org/images/mozilla-banner.gif
and the image was published as specified.

What I see happening is that the image is requested but no content-length header
is specified.

Comment 10

[Vadim Berezniker]

Yes, that seems to be the problem.
When I was sniffing packets, I paid no attention to the way that the image was
downloaded. 
I presumed that since it was already displayed, that it would be placed in the
cache. 
Other images work OK.

Comment 11

[Christine Wozniak]

Adding custrtm-; no impact on customization.

Comment 12

[Kathleen :Brade]

This problem if fixed on the trunk except when the image is > 8K (or some magic
number like that).  FUTURE for now for dealing with the real problem (need to
store the data in a temporary place until we've received it all before we can
push it off into our stream which will eventually be uploaded).

Comment 13

[Jaime Rodriguez, Jr.]

Removing [adt2] for now, since this has been futured.

Is this fixed on the branch too? If no, then pls nominate for nsbeta1. thanks!

Comment 14

[Kathleen :Brade]

-->

Comment 15

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420