Closed Bug 163109 Opened 22 years ago Closed 10 years ago

Should not throw cookie dialogs when fetching favicons

Categories

(Camino Graveyard :: General, defect, P3)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: sfraser_bugs, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 obsolete file) 

Some sites (e.g. netscape.com) set cookies when you request the favicon, which
is undescribably evil. We need to somehow block cookies for these requests, to
avoid lots of dialogs popping up for some users.
dougt suggests that I do the URI load with the LOAD_BACKGROUND flag. However,
the cookie does not respect this flag, and still throws up cookie dialogs. If
the LOAD_BACKGROUND flag is set, then the cookie code should do some default
behaviour (reject the cookie??).
Status: NEW → ASSIGNED
Attached patch nsCookieHTTPNotify.cpp patch (obsolete) (deleted) — — Splinter Review 
Proposed patch.
Comment on attachment 95618 [details] [diff] [review]
nsCookieHTTPNotify.cpp patch

r=morse
but remove the #ifdef DEBUG_smfr
Attachment #95618 - Flags: review+
Can someone explain why a site is attempting to set a cookie when you request
its favicon?  And what is the consequence of ignoring that for netscape.com? 
Would we be subverting some revenue-scheme here by rejecting such cookies?
I really hope you meant to put a smiley face somewhere in that last comment. 
(T-minus 3 hours till vacation.)

Even if there was some kind of money making thing with cookies on a favicon
requests, it is orthoganal.  The point, is there needs to be a way to request
urls without any UI.


 
Response from request for http://www.netscape.com/favicon.ico:

HTTP/1.0 302 Found
set-cookie: dcisid=2162760476.1029467957.279324; path=/
P3P: CP="NOI OUR PSA DEV PSD STA"
Location: http://wp.netscape.com/favicon.ico
MIME-Version: 1.0
Date: Fri, 16 Aug 2002 21:32:30 GMT
Server: AOLserver/3.4.2
Content-Type: text/html
Content-Length: 311
Connection: close

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML>
<HEAD>
<TITLE>Redirection</TITLE>
</HEAD>
<BODY>
<H2>Redirection</H2>
<A HREF="http://wp.netscape.com/favicon.ico">The requested URL has moved here.</A>
<P ALIGN=RIGHT><SMALL><I>AOLserver/3.4.2 on http://www.netscape.com</I></SMALL></P>

</BODY></HTML>

No, I was being dead serious.

If my understanding is correct (and maybe it's not), favicon is only for the
icon to be displayed along with the URL name.  So is there any reason for a site
to be sending a set-cookie header along with such a response?  In particular,
why is netscape doing it?

Or is it the case that the netscape server is configured to automatically send
back a cookie, and they don't distinguish between a favicon request and a
real-content request?
I would guess the latter. Note also the 302 response, which causes us to hit the
net every time, rather than relying on the cache. This reeks of poor site
management.
Shouldn't the 'OS' be set to 'Mac OS X'
OS: Mac System 9.x → MacOS X
Attachment #95618 - Flags: needs-work+
Comment on attachment 95618 [details] [diff] [review]
nsCookieHTTPNotify.cpp patch

i spoke to simon about this patch... LOAD_BACKGROUND is used when loading other
content such as that initiated after the page has finished loading (e.g.,
content loaded from an onLoad handler, or a mouseover, etc.), so this patch is
unfortunately no good.	what we really need is some other flag to communicate
this to cookies.  however, cookies are rather transparent to necko, so adding a
new load flag isn't such a great option.
Comment on attachment 95618 [details] [diff] [review]
nsCookieHTTPNotify.cpp patch

Obsoleting patch
Attachment #95618 - Attachment is obsolete: true
Blocks: 120352
Could some one update this bug?
Reassigning to necko folks.
Assignee: sfraser → darin
Status: ASSIGNED → NEW
Status update? Anyone still looking at this bug? What's the possibility for a
1.0 target?
Darin, any changes here?
Priority: -- → P3
Target Milestone: --- → Camino1.0
(In reply to comment #15)
> Darin, any changes here?
> 

Ping?
Target Milestone: Camino1.0 → Camino1.1
Assignee: darin → nobody
QA Contact: winnie → general
Target Milestone: Camino1.1 → Camino2.0
Target Milestone: Camino2.0 → ---
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: