Skip to content

InvalidURL error when NO_PROXY environment variable contains newline characters #3303

Description

@yie1d

Confirm this is an issue with the Python library and not an underlying OpenAI API

  • This is an issue with the Python library

Describe the bug

When the NO_PROXY environment variable contains newline characters (common in Docker environments, .env files, or shell scripts), creating an OpenAI client raises InvalidURL.

The error occurs because httpx's get_environment_proxies() only splits NO_PROXY by comma ,, not by newline \n. When a newline is present in the value, it becomes part of the hostname and triggers
URL validation failure.

The fix in httpx would be trivial, but the encode/httpx project is currently not actively accepting external PRs or issues.

Suggesting that openai-python sanitize proxy-related environment variables when initializing the internal httpx client.

To Reproduce

import os
os.environ['NO_PROXY'] = 'localhost\n192.168.1.1'

from openai import OpenAI
client = OpenAI(api_key='sk-test')

Error:
httpx.InvalidURL: Invalid non-printable ASCII character in URL, '\n' at position 16

Code snippets

Root cause trace:

  # 1. stdlib returns raw value with newline
  from urllib.request import getproxies
  import os
  os.environ['NO_PROXY'] = 'localhost\n192.168.1.1'
  print(getproxies())
  # {'no': 'localhost\n192.168.1.1', ...}

  # 2. httpx splits only by comma, newline stays in hostname
  from httpx._utils import get_environment_proxies
  print(get_environment_proxies())
  # {'all://*localhost\n192.168.1.1': None, ...}

  # 3. httpx URL parser rejects non-printable character
  import httpx
  httpx.Client()
  # InvalidURL: Invalid non-printable ASCII character in URL, '\n' at position 16

  Workaround:

  import os
  for key in ("NO_PROXY", "no_proxy"):
      val = os.environ.get(key)
      if val and "\n" in val:
          os.environ[key] = ",".join(
              part.strip() for part in val.replace("\n", ",").split(",") if part.strip()
          )

  from openai import OpenAI  # now works

OS

Windows / Linux (any)

Python version

3.11+

Library version

openai: latest

Activity

  1. nightcityblade commented on May 24, 2026

    @nightcityblade
    Contributor

    Hi, I'd like to work on this. I'll submit a PR shortly.

  2. added a commit that references this issue on Jun 11, 2026
    8125b58
  3. devShaik010 commented on Jun 19, 2026

    @devShaik010

    If this is still open and there is no active PR in progress, I would like to take a look. The environment sanitization path seems small enough to verify with a focused repro and test.

  4. Muhtasim-Munif-Fahim commented on Jun 19, 2026

    @Muhtasim-Munif-Fahim

    Implemented in the existing PR for this branch. The client now temporarily normalizes NO_PROXY /
    o_proxy values before constructing the default httpx client, so newline-delimited entries no longer crash client initialization on Windows or Unix. I added regression tests for both sync and async constructors.

  5. devShaik010 commented on Jun 25, 2026

    @devShaik010

    Thanks. I will step back from this since there is already an active fix in progress.

  6. Monkiia commented on Jun 27, 2026

    @Monkiia

    Stepping back here since there is already an active fix in progress for this issue. I don't want to duplicate effort.

  7. nightcityblade commented on Jul 3, 2026

    @nightcityblade
    Contributor

    Hi, I'd like to work on this. I'll submit a PR shortly.

  8. added a commit that references this issue on Jul 20, 2026
    217dc74
  9. Xsidz commented on Aug 16, 2026

    @Xsidz

    Working on this in PR #3631.

  10. marcuswood-oai commented on Sep 9, 2026

    @marcuswood-oai
    Contributor

    Thank you for the report. We understand how multiline Docker Compose configuration can lead to this. HTTPX2 expects a comma-separated NO_PROXY list, so please use NO_PROXY=localhost,192.168.1.1 rather than separating the hosts with newlines.

    We’re closing this because we’re keeping the SDK consistent with HTTPX2’s proxy parsing. Broader separator support belongs in the transport library; we won’t add SDK-specific normalization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions