HttpOnly cookie in Firefox's cookies.txt begins with "#HttpOnly_" now,
just like a comment, e.g.:

#HttpOnly_.rad.live.com TRUE / FALSE 1258200001 FC09 FB=
#HttpOnly_service.ilib.cn FALSE / FALSE 1209905939
.ASPXANONYMOUS
JMeD5-atyAEkAAAAYjZlNDUyNDAtOGQ4ZC00NTEyLTljN2EtMzNkODM3M2JjMjFivtX6ikB7Iv0jRJBJs9ftggv_a2k

Since no obvious need, there are no patches for save method and
cookielib.Cookie class.

I think firefox 3 no longer writes cookies.txt (it writes cookies.sqlite
instead).

Can anybody point out a version of firefox that wrote this HttpOnly
information to cookies.txt, so the patch can be tested?

MozillaCookieJar is now a class in http.cookiejar, so patch would need update. Is this still used enough to bother?

Firefox no longer use cookies.txt. I think this patch is useless.

Would you suggest removing MozillaCookieJar from the module?
(Through the normal warn-deprecate-remove process.)

Is deprecation really necessary? lynx still uses that format. lynx doesn't write the header that MozillaCookieJar insists on being present, but a trivial subclass can read cookies files written by lynx.

Dear all,

In fact, this cookie.txt format is still used by curl. For instance, see

https://github.com/bagder/curl/blob/curl-7_39_0/lib/cookie.c#L644

which clearly shows support for the "#HttpOnly_" prefix. Therefore, supporting this format in http.cookiejar.MozillaCookieJar seems quite relevant to me.

Attached is an updated patch.

Kind regards,
Jérémie.

Can this issue be reopened? As Jérémie stated, curl uses this format and outputs cookie files using the #HttpOnly_ prefix. I also found at least one project that is working around lack of this support:
https://code.google.com/archive/p/git-repo/
https://gerrit.googlesource.com/git-repo/+/master/subcmds/sync.py#995
# Python doesn't understand cookies with the #HttpOnly_ prefix
# Since we're only using them for HTTP, copy the file temporarily,
# stripping those prefixes away.

One potential improvement for the proposed patch: instead of just stripping out #HttpOnly_, this attribute should be set on the Cookie that is created, within the 'rest' dict (rest={'HttpOnly': True}). The Morsel class is already aware of this attribute, as is the 'requests.cookies' module.

Also confused about why this was closed.

This format is still frequently used. In the absence of a solution in the standard library, I'm using this kludge to strip the leading #HttpOnly_.

    from tempfile import NamedTemporaryFile
    from http.cookiejar import MozillaCookieJar
    from contextlib import contextmanager

    def fix_cookie_jar_file(orig_cookiejarfile):
        with NamedTemporaryFile(mode='w+') as cjf:
            with open(orig_cookiejarfile, 'r') as ocf:
            for l in ocf:            
                cjf.write(l[10:] if l.startswith('#HttpOnly_') else l)
            cjf.seek(0)
        yield cjf.name

    MozillaCookieJar(filename=fix_cookie_jar_file(orig_cookiejarfile))

This issue was closed as useless for Firefox in 2010 by the original poster, msg109958. My participation here is only as tracker triager, as I only have a consumer knowledge of cookies. Unfortunately, there is no core developer expert for http, let alone the http.cookiejar. The person who once handled some cookie related patches is no longer active.

Adding a patch to a closed issue is somewhat useless. In any case, a possible revised PR would be needed. My suggestion is to ask on python-ideas whether this enhancement might be accepted now and whether better to reopen this issue or open a new one.

I've got a patch that will address both loading and saving of "HTTP-only" cookies: master...dlenski:patch-1

Testing/feedback before I submit as a PR would be very welcome.

@terry.reedy, it looks like my PR just needs a core developer to review it. Would you mind taking a look? :-)

#22798

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
Describes the purpose of the HttpOnly attribute used in PR.

Issue bpo-38976 is a duplicate of this one, and now closed by #17471

So, is anything more needed, or should PR-22798 and this issue be closed?

This can be closed.

Yes. The required 'feature' was introduced through #17471 even as the patches were slightly different. But keeping #17471 seems fine and we can close this ticket and the PR.