CookieContainer handling of paths (Who ate my cookie?)

主宰稳场 提交于 2019-11-30 13:35:29

When a path is not specified, I had assumed that the cookie would be sent back to any page in that domain, but it seems to only get sent back to that specific page. I'm now assuming that is correct as it is consistent.

Yep, that's correct. Whenever domain or path is not specified, it's taken from current URI.

OK, let's take a look at CookieContainer. The method in question is InternalGetCookies(Uri). Here's the interesting part:

while (enumerator2.MoveNext())
{
    DictionaryEntry dictionaryEntry = (DictionaryEntry)enumerator2.get_Current();
    string text2 = (string)dictionaryEntry.get_Key();
    if (!uri.AbsolutePath.StartsWith(CookieParser.CheckQuoted(text2)))
    {
        if (flag2)
        {
            break;
        }
        else
        {
            continue;
        }
    }
    flag2 = true;
    CookieCollection cookieCollection2 = (CookieCollection)dictionaryEntry.get_Value();
    cookieCollection2.TimeStamp(CookieCollection.Stamp.Set);
    this.MergeUpdateCollections(cookieCollection, cookieCollection2, port, flag, i < 0);
    if (!(text2 == "/"))
    {
        continue;
    }
    flag3 = true;
    continue;
}

enumerator2 here is a (sorted) list of cookies' paths. It is sorted in such a way, that more specific paths (like /directory/subdirectory/) go before less specific ones (like /directory/), and otherwise - in lexicographical order (/directory/page1 goes before /directory/page2).

The code does actually the following: it iterates over this list of cookies' paths until it finds a first path, that is a prefix for requested URI's path. Then it adds a cookies under that path to the output and sets flag2 to true, which means "OK, I finally found the place in the list that actually relate to requested URI". After that, the first met path, that is NOT a prefix for requested URI's path is considered to be the end of related paths, so the code stops searching for cookies by doing break.

Obviously, this is some kind of optimization to prevent scanning the whole list and it apparently works if none of paths leads to concrete page. Now, for your case, the path list looks like that:

/some/path/page1.html
/some/path/page2.html
/some/path/

You can check that with a debugger, looking up ((System.Net.PathList)(cookieJar.m_domainTable["www.somedomain.com"])).m_list in watch window

So, for 'page1.html' URI, the code breaks on page2.html item, not having a chance to process also /some/path/ item.

In conclusion: this is obviously yet another bug in CookieContainer. I believe it should be reported on connect.

PS: That's too many bugs per one class. I only hope the guy at MS who wrote tests for this class is already fired.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!