feat: add tls options support

[arturfromtabnine]

Description

Add tls options support. Supporting custom Certificate Authority + Ignore certificate issues.
Options can be send via x-portkey-tls-options header which is parsed later on and used for custom https agent.

This change adds flexibility for enterprise network environments where we do need to support per-model certificate configuration while maintaining deployment flexibility.

Examples:

import Portkey from "portkey-ai";

const client = new Portkey({
      ...config,
      tlsOptions: {
        rejectUnathorized: false
      },
    });

curl http://localhost:8787/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "x-portkey-tls-options: {\"rejectUnathorized\": \"false\"}" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

Motivation

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)

How Has This Been Tested?

• Unit Tests
• Integration Tests
• Manual Testing

Screenshots (if applicable)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Related Issues

[matter-code-review]

Description

Summary By MatterAI

🔄 What Changed

This PR refines the TLS options support by removing cert and key from the getCustomHttpsAgent options, focusing the utility on custom Certificate Authority (CA) and rejectUnauthorized settings. The overall feature adds support for TLS options in outgoing requests, allowing users to customize TLS settings such as providing custom CA certificates or disabling certificate validation. These options can be sent via the x-portkey-tls-options header, which is parsed and used to configure a custom HTTPS agent for fetch requests.

🔍 Impact of the Change

This change enables users to connect to API endpoints that use custom or self-signed certificates by providing their own CA certificates or optionally disabling certificate validation. This is particularly useful in enterprise environments with private PKI infrastructure or when connecting to development/staging environments with non-standard certificates. It adds required flexibility for enterprise network requirements while maintaining deployment flexibility.

📁 Total Files Changed

• src/utils/fetch.ts: Modified to remove cert and key options from getCustomHttpsAgent.
• package.json: Added undici dependency for HTTP client functionality.
• src/handlers/handlerUtils.ts: Modified to support TLS options in request configuration.
• src/types/requestBody.ts: Added TLS options interface to provider options.
• tests/unit/src/utils/fetch.test.ts: Added comprehensive tests for the new TLS agent functionality.

🧪 Test Added

Comprehensive unit tests were added for the getCustomHttpsAgent function, covering: Default behavior (rejectUnauthorized = true), Custom options for certificate validation, Support for custom CA certificates (both string and Buffer formats), Edge cases including null/undefined handling, and Various parameter combinations and validation.

🔒Security Vulnerabilities

The implementation includes a security note warning about the potential risks of disabling certificate validation. While the code allows disabling certificate validation (rejectUnauthorized = false), this is clearly documented as a security consideration. The implementation follows security best practices by making certificate validation enabled by default and requiring explicit configuration to disable it.

Motivation

Add tls options support. Supporting custom Certificate Authority + Ignore certificate issues. Options can be send via x-portkey-tls-options header which is parsed later on and used for custom https agent. This change adds required flexibility for enterprise network requirements where we do need to support per-model certificate configuration while maintaining deployment flexibility.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)

How Has This Been Tested?

• Unit Tests
• Integration Tests
• Manual Testing

Screenshots (if applicable)

N/A

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Related Issues

N/A

Tanka Poem ♫

New TLS paths gleam,
Certificates now align,
Secure data flows.
No more handshake errors, clear,
Enterprise networks cheer. 🌐✨

Sequence Diagram

sequenceDiagram
    participant Client
    participant RequestHandler
    participant UtilsFetch
    participant HttpsAgent
    participant ExternalAPI

    Client->>RequestHandler: HTTP Request (with x-portkey-tls-options header)
    RequestHandler->>RequestHandler: Parse x-portkey-tls-options header
    RequestHandler->>UtilsFetch: Call getCustomHttpsAgent(tlsOptions)
    UtilsFetch->>HttpsAgent: Create custom HttpsAgent (rejectUnauthorized, ca)
    HttpsAgent-->>UtilsFetch: Return configured Agent
    UtilsFetch-->>RequestHandler: Return configured Agent
    RequestHandler->>ExternalAPI: Make HTTPS Request (using custom Agent)
    ExternalAPI-->>RequestHandler: API Response
    RequestHandler-->>Client: HTTP Response

Loading

[matter-code-review]

This PR adds TLS options support for outgoing requests, which is a valuable feature for enterprise environments. The implementation is well-structured with good test coverage. I have a few suggestions to improve security awareness and error handling.

Skipped files

• package-lock.json: Skipped file pattern

[matter-code-review]

Important

PR Review Skipped

PR review skipped as per the configuration setting. Run a manually review by commenting /matter review

💡Tips to use Matter AI

Command List

• /matter summary: Generate AI Summary for the PR
• /matter review: Generate AI Reviews for the latest commit in the PR
• /matter review-full: Generate AI Reviews for the complete PR
• /matter release-notes: Generate AI release-notes for the PR
• /matter : Chat with your PR with Matter AI Agent
• /matter remember : Generate AI memories for the PR
• /matter explain: Get an explanation of the PR
• /matter help: Show the list of available commands and documentation
• Need help? Join our Discord server: https://discord.gg/fJU5DvanU3

[narengogi]

I feel this is not the best approach for configuring tls, we could allow configuring environment variables for tls cert and certificate authority paths instead of passing it in request

[arturfromtabnine]

I feel this is not the best approach for configuring tls, we could allow configuring environment variables for tls cert and certificate authority paths instead of passing it in request

proposed approach is more flexible than setting NODE_EXTRA_CA_CERTS/NODE_TLS_REJECT_UNAUTHORIZED which will affect all the requests.
ie. in our case one particular model endpoint need to have tls check disabled or different CA used for different models sitting behind different proxies with in same installation/setup.
envs do not give us that flexibility
let me know if you see it other way

[narengogi]

I feel this is not the best approach for configuring tls, we could allow configuring environment variables for tls cert and certificate authority paths instead of passing it in request

proposed approach is more flexible than setting NODE_EXTRA_CA_CERTS/NODE_TLS_REJECT_UNAUTHORIZED which will affect all the requests. ie. in our case one particular model endpoint need to have tls check disabled or different CA used for different models sitting behind different proxies with in same installation/setup. envs do not give us that flexibility let me know if you see it other way

Makes sense

[narengogi]

looks good to me!