RFC question about cookies and paths

I'm trying to set a session cookie restricted to a particular path (let's say /foo)开发者_如何转开发 when a user logs in. The complication being that the login page is on /, but the request immediately redirects to /foo/something. Something like this:

Request:

POST / HTTP/1.1

username=foo&password=bar

Response:

HTTP/1.0 302 Found
Location: http://example.com/foo/home
Set-Cookie: session=whatever; path=/foo

However, the relevant bits of the RFCs I could find (rfc2109 and rfc2965) say this:

To prevent possible security or privacy violations, a user agent rejects a cookie (shall not store its information) if any of the following is true:

• The value for the Path attribute is not a prefix of the request- URI.

...

The cookie-setting process described above seems to work okay, but as far as I can tell the RFCs are saying it shouldn't.

I'd like to use this in a production system, but I really don't want to do that if I'm going to face horrible browser incompatibility problems later.

Am I misreading the RFCs?

Thanks in advance!

---

Don't pay any attention to those RFCs; they diverge from reality pretty badly.

There's currently an IETF WG that's documenting actual cookie behaviour; their document, while just a draft, is much better source material.

See: http://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/

If you don't find text that addresses your question in the draft, bring it up with the Working Group!

---

Based on your question, I think your understanding of the RFC is correct. It sounds like you want to set the cookie after the redirect to '/foo/home'. I think the real question is: "How do you tell '/foo/home' that the user was authenticated correctly by '/'?"

If you must use a Location header (redirect) to get from '/' to '/foo/home', it seems the only way to do this would be to use a query string parameter in the Location header's value.

Maybe a design question to consider is: why are users authenticating against a URL outside of the path they will be accessing securely? If the only secure content is under '/foo', then why not POST to '/foo/login' instead of '/' for authentication?