Closed Bug 163109 Opened 23 years ago Closed 11 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) — — 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: 11 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: