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

Status: VERIFIED FIXED

(Core :: Networking: Cookies, defect, P3)

Description

[Shankar N]

<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

[Stephen P. Morse]

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.

Comment 2

[Judson Valeski]

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

[Gagan]

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. 

Comment 4

[leger]

Putting on PDT+ radar for beta1.

Comment 5

[Judson Valeski]

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.

Comment 6

[Judson Valeski]

fix just checked in.

Comment 7

[Gagan]

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

[Gagan]

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... :-(

Comment 9

[Judson Valeski]

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

[Tom Everingham]

verified:
NT 2000021408