241588 - Image save failure on some secure sites.

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Joshua Simmons]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040424 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040424 Firefox/0.8.0+

Since the sites are secure, I can't easily give an example, here is what I can give.
Earliest I have seen this is the 4/10 build, and it is present in the 4/24 build
as well, but I haven't seen it in the 0.8 release.

When attempting to save images on some secure sites, where the images are
protected from access by those not logged in, images saves (or views, right
click, view image) do not load the correct data when the image is not in the
cache, as if it is not using cookies when fetching it, and not even realising
when it gets something other than what it asked for.

Reproducible: Always
Steps to Reproduce:
1. Go to a secure site that redirects access attempts to another page if your
not logged in.
2. Find an image that is redirected such. (call it "theimage.jpg" for this example)
3. Clear the cache
4. Try to save the image.

Actual Results:  
The HTML file that is redirected to when someone not logged in, usually the
main/login page on most sites, will instead be saved with the filename
"theimage.html" (extension might depend on the derirect pages extension, not sure)

Expected Results:  
The image should have been saved properly.

Save image as, View image, and Save Page as are all effected, if the image is
still in the cache it works fine. I can't find a good example that everone would
be able to access since it relates to secure sites, so I have to hope you can
find your own example. I can't say if it effects other file types, the only
files available which are part of the page to test with are images.

Comment 1

[Stefan A. Möller]

Maybe this one is related to bug 242412? You can find an example there. However,
that one is not dealing with a secure site.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I'm sure we send cookies and basicauth info with the persistence object
requests... so is this a referrer issue?

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

I'm not so sure about basic auth... consider bug 146574 and bug 183572 (which
sound like duplicates)

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

(cc'ing bz so he sees my last comment)

Comment 5

[Boris Zbarsky [:bzbarsky]]

Those are both FTP bugs.  BasicAuth is HTTP-only.  FTP has no concept of
"secure", so I highly doubt this bug is FTP-related.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

*shrug*, if you say so...

(In reply to comment #2)
> I'm sure we send cookies and basicauth info with the persistence object
> requests... so is this a referrer issue?

don't we also send referer? I made such a patch to seamonkey's contentAreaUtils
after seeing that firefox had a checkin for that...
I'm not quite sure whether that fixes save image as though...

Comment 7

[Boris Zbarsky [:bzbarsky]]

It should; goes through the same code...

So I think we need a bit more information from reporter here (say HTTP logs).

Comment 8

[Joshua Simmons]

Looking at this, it does look very much like bug 242412, with a possible
difference or two, and I will look into it a little more. It is possible it is
the same, since most of the pages I was having trouble with were PHP generated.
I will bug the dev a bit more about the page, check if I got a response to my
last message. Once case was one a phpBB 2.0.6 users only board IIRC.

Comment 9

[Martijn Wargers (dead)]

This could very well be fixed when bug 160454 got fixed. 
Reporter, could you try it with a Mozilla (not Firefox) build later than 2004-10-10?

Comment 10

[OstGote!]

No response, marking WFM. Feel free to reopen if the problem persists with
current builds.