<meta http-equiv="Set-Cookie" content="BROWSERTEST=SUPPORTS_COOKIES; path=/">

VERIFIED FIXED in M14

Status

()

P3
normal
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: nshankar, Assigned: jud)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

(Reporter)

Description

19 years ago
<meta http-equiv="Set-Cookie" content="BROWSERTEST=SUPPORTS_COOKIES; path=/">
Works on netscape. Sets a session cookie.
Does not work on mozilla M13 or M12.

Comment 1

19 years ago
Sounds like this is problem in the protocol level of necko rather than in the 
cookie module.  Assiging to Jud.  Jud, if you determine that the problem really 
is in the cookie module, then please reassign it back to me.
Assignee: morse → valeski
(Assignee)

Comment 2

19 years ago
yet another joyous http-equiv tag. I think I'll hook the cookie module up to the 
HTML content sink so these can be captured.

Comment 3

19 years ago
I think we should hook the HTTP observer to the HTML content sink so that any 
future similar cases (and not just cookies) can be caught. 

Updated

19 years ago
Keywords: beta1
Target Milestone: M14

Comment 4

19 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
(Assignee)

Comment 5

19 years ago
Gagan, I think you're trying to tackle a different problem (header 
notification). The HTTP-EQUIV stuff stick headers inside html. I think we should 
treat this like the hack that it is. If we try to generalize we have to cross 
the "parser controling the HTTP protocol" bridge.
Status: NEW → ASSIGNED
(Assignee)

Comment 6

19 years ago
fix just checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 7

19 years ago
Jud: but isn't it true that the HTTP-EQUIV can potentially have other HTTP 
headers? Like- 

Expires // for cache work
Set-Cookie // for cookies - covered here. 
Refresh // for auto refreshes

Comment 8

19 years ago
Oh crap! I was just checking on the spec. Looks like this is another one of the 
misinterpreted features of HTML. According to the HTML spec-

"The http-equiv attribute can be used in place of the name attribute and has a 
special significance when documents are retrieved via the Hypertext Transfer 
Protocol (HTTP). HTTP servers may use the property name specified by the 
http-equiv attribute to create an [RFC822]-style header in the HTTP response"

As you see this is a suggested property for the HTTP servers to use and the spec 
doesn't mention much about clients. It seems to me that HTTP-EQUIV should not be 
handled by the client at all... but I guess for the quirk-compatibility-mode we 
will have to do this... :-(
(Assignee)

Comment 9

19 years ago
you got it. it's a hack that sort of fit into old models. technically *any* HTTP 
header can show up there. However only a few have ever been handled. among them:

set-cookie: which we now cover
refresh: which we cover
expires: which should hook up w/ the cache.

If you'll recall, associating an HTTP header with an nsDocument is not easy to 
do. A document has no concept of a channel. The two are totally broken apart. 
There's only so much "reflow" we can do (at this point none) between a document 
that has already been parsed and HTTP. The two concepts are simply disjoint. I 
talked to vidur about associating a channel w/ a doc, and he argued that the two 
should know as little (if anything) about eachother as possible. Connecting the 
doc to the channel makes some wierd incestuous relationships (circular in some 
cases I would suspect). So, if we don't bind the two, there isn't even a way to 
access the channel to set headers on it.

Comment 10

19 years ago
verified:
NT 2000021408
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.