<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.
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
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.
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.
Putting on PDT+ radar for beta1.
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
fix just checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
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
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... :-(
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.
verified: NT 2000021408
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.