python / python/cpython

CookieDefaultPolicy.set_port_ok and return_ok_port func does not work for IPv6 addresses

Open
#135,993 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

stdlib type-bug
Dominant language
Python
Stars
77.2k
Forks
35.9k
PR merge metrics
PR metrics pending

Description

Bug description:

POC:

import urllib.request
from http.cookiejar import CookieJar, DefaultCookiePolicy
class FakeResponse:
    def __init__(self, headers=[], url=None):
        """
        headers: list of RFC822-style 'Key: value' strings
        """
        import email
        self._headers = email.message_from_string("\n".join(headers))
        self._url = url
    def info(self): return self._headers
pol = DefaultCookiePolicy(
            rfc2965=True, blocked_domains=[])
c = CookieJar(policy=pol)
c.clear()
headers = ["Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; port=1234"]
req = urllib.request.Request("http://127.0.0.1:1234")
res = FakeResponse(headers, "http://127.0.0.1:1234")
print(pol.set_ok_port(c.make_cookies(res, req)[0], req))
print(pol.return_ok_port(c.make_cookies(res, req)[0], req))
# output: True, True

req_IPv6 = urllib.request.Request("http://[::1]:1234")
res_IPv6 = FakeResponse(headers, "http://[::1]:1234")
print(pol.set_ok_port(c.make_cookies(res_IPv6, req_IPv6)[0], req_IPv6))
print(pol.return_ok_port(c.make_cookies(res_IPv6, req_IPv6)[0], req_IPv6))
# output: False, False

Well, port 1234 is the correct port. Then why request with host [::1] always return False?
Let's dive in to the function:

    def set_ok_port(self, cookie, request):
        if cookie.port_specified:
            req_port = request_port(request)
            if req_port is None:
                req_port = "80"
            else:
                req_port = str(req_port)
            for p in cookie.port.split(","):
                try:
                    int(p)
                except ValueError:
                    _debug("   bad port %s (not numeric)", p)
                    return False
                if p == req_port:
                    break
            else:
                _debug("   request port (%s) not found in %s",
                       req_port, cookie.port)
                return False
        return True

So, the req_port is set by func request_port(), lets check it:

def request_port(request):
    host = request.host
    i = host.find(':')
    if i >= 0:
        port = host[i+1:]
        try:
            int(port)
        except ValueError:
            _debug("nonnumeric port: '%s'", port)
            return None
    else:
        port = DEFAULT_HTTP_PORT
    return port

So that's where thing goes wrong. if the input of request_port is an IPv6 addr like [::1]. It will actually always raises a ValueError and return None caz it tries to int(":1]:1234") instead of int("1234") and the port will be forced to 80. Which not equals to 1234, and returns False.

It is totally not a rocket science to solve this, but I need the helper functions of IPv6 in #135768 to land before the PR. I've already completed the PR based on the helper functions,

Same thing works for return_ok_port

cc @picnixz here if you have more advice, thanks!

CPython versions tested on:

3.14

Operating systems tested on:

Windows

Linked PRs
  • gh-136076

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with request_port(), set_ok_port(), and return_ok_port(), then run the IPv4 and IPv6 reproducer in the issue. Check the related IPv6 helper work in gh-135768 and the linked PR gh-136076; the issue is done when port 1234 is accepted for both address forms without regressing the IPv4 behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
networking
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.