robobun dd7a639a6f fix(serve): correct TLS array validation for SNI (#21796) ...

## Summary

Fixes a prerequisite issue in #21792 where `Bun.serve()` incorrectly
rejected TLS arrays with exactly 1 object.

The original issue reports a WebSocket crash with multiple TLS configs,
but users first encounter this validation bug that prevents
single-element TLS arrays from working at all.

## Root Cause

The bug was in `ServerConfig.zig:918` where the condition checked for
exactly 1 element and threw an error:

```zig
if (value_iter.len == 1) {
    return global.throwInvalidArguments("tls option expects at least 1 tls object", .{});
}
```

This prevented users from using the syntax: `tls: [{ cert, key,
serverName }]`

## Fix

Updated the validation logic to:
- Empty TLS arrays are ignored (treated as no TLS)  
- Single-element TLS arrays work correctly for SNI
- Multi-element TLS arrays continue to work as before

```zig
if (value_iter.len == 0) {
    // Empty TLS array means no TLS - this is valid
} else {
    // Process the TLS configs...
}
```

## Testing

- ✅ All existing SSL tests still pass (16/16)
- ✅ New comprehensive regression test with 7 test cases 
- ✅ Tests cover empty arrays, single configs, multiple configs, and
error cases

## Note

This fix addresses the validation issue that prevents users from
reaching the deeper WebSocket SNI crash mentioned in #21792. The crash
itself may require additional investigation, but this fix resolves the
immediate blocker that users encounter first.

---------

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>

2025-08-15 21:25:54 -07:00

3.5 KiB

Raw Permalink Blame History

View Raw