If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/sta/websocket-sharp shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Solo project — review before adopting

• Last commit 3w ago
• MIT licensed
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live sta/websocket-sharp repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sta/websocket-sharp.

What it runs against: a local clone of sta/websocket-sharp — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in sta/websocket-sharp | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 49 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sta/websocket-sharp. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sta/websocket-sharp.git
#   cd websocket-sharp
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of sta/websocket-sharp and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sta/websocket-sharp(\\.git)?\\b" \\
  && ok "origin remote is sta/websocket-sharp" \\
  || miss "origin remote is not sta/websocket-sharp (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 49 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~19d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/sta/websocket-sharp"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

websocket-sharp is a fully RFC 6455-compliant WebSocket protocol implementation for C# that provides both client and server APIs. It runs on .NET Framework 3.5+ (and Mono) and handles WebSocket upgrades, per-message compression, secure TLS connections, HTTP authentication, and cookie management—eliminating the need to hand-code WebSocket framing or rely on platform APIs. Monolithic assembly design: websocket-sharp/ contains the core library split into logical modules (Net/ folder with HTTP layer, HttpRequest.cs, HttpResponse.cs, protocol enums like Fin.cs, Mask.cs, LogLevel.cs), while Example/, Example2/, and Example3/ are separate projects demonstrating Echo and Chat functionality. The Logger.cs and LogData.cs utilities provide observability; no separate test directory is listed.

C# backend engineers and .NET developers building real-time applications (chat servers, live dashboards, gaming backends) who need a standalone, cross-platform WebSocket library that doesn't depend on IIS or System.Net.WebSockets.

This project is mature and stable: the master branch targets RFC 6455 (standardized 2011), supports back to .NET 3.5, and includes three working example projects (Example/, Example2/, Example3/). However, the repo shows signs of slower maintenance—no recent commit date visible in the file list, and it's listed as a prerelease on NuGet. It is production-ready for established use cases but may not receive rapid updates for new .NET Core/Framework versions.

Standard open source risks apply.

No active development commits or PR activity is evident from the file list alone. The repo appears to be in maintenance mode—existing code is stable, but there is no visible roadmap for .NET 5+, async/await modernization, or performance tuning.

git clone https://github.com/sta/websocket-sharp.git
cd websocket-sharp
# Open websocket-sharp.sln in Visual Studio or MonoDevelop and build the 'websocket-sharp' project configuration (Debug or Release)
# Or use: msbuild websocket-sharp.sln /p:Configuration=Debug

Daily commands: Client example: Open websocket-sharp.sln → build Example project → run Example.exe. Server example: Build and run Example2/Program.cs or Example3/Program.cs (Example3 includes a web UI in Public/index.html + echotest.js). No dotnet CLI or npm commands needed; compile with MonoDevelop or Visual Studio.

• websocket-sharp/Ext.cs: Extension methods and utility functions that support WebSocket frame construction and parsing across the codebase
• websocket-sharp/Net/HttpConnection.cs: Core socket handler for the WebSocket upgrade handshake and low-level I/O; critical for both client and server connection lifecycle
• websocket-sharp/Logger.cs: Centralized logging infrastructure (used throughout library); configure here to debug frame handling and connection state
• websocket-sharp/CloseStatusCode.cs: Enum defining all RFC 6455 close codes (1000, 1001, 1009, etc.); essential for proper connection teardown semantics
• Example2/Echo.cs: Simplest reference implementation for a WebSocket echo server behavior; start here to understand the API
• websocket-sharp/Net/EndPointListener.cs: Server-side listener abstraction that manages socket bind and connection acceptance; understand this for server-side modifications

• WebSocket frame parsing: edit websocket-sharp/*.cs (Fin.cs, Mask.cs, LogData.cs for low-level frame handling). - Protocol events: modify WebSocket.cs OnMessage/OnError/OnClose delegates. - HTTP upgrade handshake: edit websocket-sharp/Net/HttpRequest.cs, HttpResponse.cs, HttpConnection.cs. - New server features: extend WebSocketServer in websocket-sharp/ (not visible but implied by examples). - Examples: modify Example/Program.cs, Example2/Chat.cs, Example2/Echo.cs for reference implementations.

• Mono/Framework version matrix: library targets .NET 3.5 but examples may assume newer features; verify target framework in *.csproj files before building. - No async/await: WebSocket.cs uses synchronous event handlers (OnMessage += ...); expect blocking semantics, not Task-based APIs—do not assume modern async patterns. - Masking requirement: client frames MUST be masked per RFC 6455; server frames MUST NOT be masked. The Mask.cs enum enforces this, but custom frame code risks violations. - Logger configuration: Logger.cs has static state; ensure you initialize it before creating WebSocket instances if you need custom log output. - Example3 requires web server: Example3/Public/ expects an HTTP server to serve static files; the console app may not auto-host HTML/JS.

• RFC 6455 WebSocket Protocol Framing — websocket-sharp's entire frame parsing logic (Fin.cs, Mask.cs, OpCode handling) implements this spec; understanding frame structure (FIN bit, opcode, payload length encoding, masking key) is essential to debug or extend the library
• WebSocket Masking (Client-to-Server) — The Mask.cs enum and masking logic in frame handling enforce RFC 6455's requirement that all client frames be XOR-masked with a random 4-byte key; missing or incorrect masking causes protocol violations and server rejection
• Hybi Handshake (HTTP Upgrade) — websocket-sharp's HttpBase.cs, HttpRequest.cs, HttpResponse.cs implement the WebSocket opening handshake (Sec-WebSocket-Key, Sec-WebSocket-Accept HMAC-SHA1 challenge); understanding this upgrade is needed to debug connection failures
• Per-Message Compression (DEFLATE) — The CompressionMethod.cs enum and per-message-deflate extension handling reduce bandwidth for large payloads; critical for mobile or high-volume use cases but adds CPU cost and implementation complexity
• Close Frame Semantics — CloseStatusCode.cs and CloseEventArgs.cs define the close handshake; improper close status codes (e.g., using 1005 in a close frame when it's reserved for abnormal closure) break client/server compatibility
• Chunked HTTP Transfer Encoding — websocket-sharp's ChunkedRequestStream.cs and Chunk.cs handle HTTP bodies streamed in chunks during handshake and server communication; necessary for proxies and large payloads that don't fit in memory
• HTTP Digest Authentication — The Net/HttpDigestIdentity.cs and AuthenticationChallenge.cs classes implement RFC 2617 Digest auth for WebSocket endpoints behind authenticated proxies; understand MD5 hashing and nonce replay protection

• aspnet/WebSockets — Official Microsoft WebSocket support for ASP.NET Core; use this if you are building on modern .NET Core/5+ instead of legacy .NET Framework
• dotnet/runtime — System.Net.WebSockets in the .NET runtime; websocket-sharp is an alternative for older .NET Framework versions or when you need a standalone, non-BCL implementation
• SignalR/SignalR — Higher-level real-time communication library (Hubs, automatic fallbacks) that can use WebSocket as transport; use if you need RPC semantics, not raw frames
• WebSocketListener/WebSocketListener — Another C# WebSocket server library; comparison point if websocket-sharp's event-driven model doesn't fit your async/await workflow
• statianzo/Fleck — Lightweight C# WebSocket server focused on simplicity; alternative if you only need server-side functionality without the full client API

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for WebSocket protocol frame parsing (websocket-sharp/Fin.cs, Mask.cs, and frame handling)

The codebase lacks visible unit test files despite having complex protocol-level code (Fin.cs for frame finalization, Mask.cs for frame masking, HttpRequest.cs/HttpResponse.cs for handshake). The WebSocket protocol is notoriously error-prone with frame parsing, masking validation, and compression handling. Adding tests would prevent regressions and validate RFC 6455 compliance mentioned in the README.

• [ ] Create a Tests/ directory structure parallel to websocket-sharp/
• [ ] Add unit tests for Fin.cs covering valid/invalid frame finalization states
• [ ] Add unit tests for Mask.cs validating masking/unmasking logic with RFC 6455 test vectors
• [ ] Add integration tests for HttpRequest.cs and HttpResponse.cs handshake parsing with edge cases (malformed headers, missing headers, invalid status codes)
• [ ] Add tests for CompressionMethod.cs validating per-message compression extension handling

Add async/await modernization for websocket-sharp/Net/HttpListener.cs and related connection handling

The README specifies support for .NET Framework 3.5+, but the codebase appears to use older async patterns (HttpListenerAsyncResult.cs, HttpStreamAsyncResult.cs). Modern .NET (4.5+) developers expect async/await. Adding parallel async/await APIs alongside legacy patterns would improve usability for contemporary projects without breaking existing code.

• [ ] Audit HttpConnection.cs and HttpListener.cs for callback-based async patterns
• [ ] Create async Task-based wrappers for core connection methods (e.g., AcceptConnectionAsync, SendAsync, ReceiveAsync)
• [ ] Add ConfigureAwait(false) patterns for library code to prevent deadlocks
• [ ] Update Example3/Program.cs to demonstrate async/await usage alongside existing examples
• [ ] Document async patterns in README.md with code snippets

Add missing documentation and examples for HTTP Authentication flows (websocket-sharp/Net/AuthenticationChallenge.cs, AuthenticationResponse.cs, HttpBasicIdentity.cs, HttpDigestIdentity.cs)

The README lists 'HTTP Authentication' as a supported feature, but there are no examples in Example/, Example2/, or Example3/ demonstrating how to use Basic or Digest authentication. The existence of AuthenticationChallenge.cs, AuthenticationResponse.cs, and two identity classes suggests this is partially implemented but undocumented. New contributors should create executable examples showing how to authenticate WebSocket connections.

• [ ] Create Example4 directory with HTTP Basic Authentication WebSocket example
• [ ] Create Example5 directory with HTTP Digest Authentication WebSocket example
• [ ] Add code comments to Net/AuthenticationChallenge.cs and Net/AuthenticationResponse.cs explaining usage flow
• [ ] Update README.md 'HTTP Authentication' section with working code snippets
• [ ] Document authentication header requirements and browser limitations (if any)

• Add unit tests for CloseStatusCode.cs and CompressionMethod.cs: these enums define critical protocol state but have no test coverage visible in the file list. Create websocket-sharp.Tests/ with xUnit or MSTest to validate enum values match RFC 6455.
• Document the ByteOrder.cs and Mask.cs utility functions with inline XML comments and a guide in README.md explaining frame endianness and masking rules; many contributors stumble on byte order in WebSocket frame encoding.
• Add a TLS/secure WebSocket (wss://) example: Example/ shows ws:// only. Create Example/SecureClient.cs demonstrating ClientSslConfiguration usage with a self-signed cert to lower the barrier for HTTPS adoption.

• High · Potential Insecure SSL/TLS Configuration — websocket-sharp/Net/ClientSslConfiguration.cs, websocket-sharp/Net/ServerSslConfiguration.cs. The codebase includes ClientSslConfiguration and ServerSslConfiguration classes. Without access to the implementation details, there's a risk that SSL/TLS validation could be disabled or improperly configured, allowing man-in-the-middle attacks. Common issues include disabling certificate validation or using outdated protocols. Fix: Review SSL/TLS implementation to ensure: (1) Certificate validation is always enabled by default, (2) Only TLS 1.2 or higher is supported, (3) Strong cipher suites are used, (4) Hostname verification is enforced
• High · HTTP Authentication Implementation Risks — websocket-sharp/Net/HttpBasicIdentity.cs, websocket-sharp/Net/HttpDigestIdentity.cs, websocket-sharp/Net/AuthenticationChallenge.cs. The codebase includes HTTP Basic and Digest authentication implementations (HttpBasicIdentity.cs, HttpDigestIdentity.cs, AuthenticationChallenge.cs, AuthenticationResponse.cs). These authentication mechanisms are known to be vulnerable without proper SSL/TLS protection. Basic auth sends credentials in Base64 encoding which is easily decoded. Fix: Ensure HTTP authentication is only used over HTTPS/WSS connections. Implement mandatory TLS enforcement. Consider recommending OAuth 2.0 or other modern authentication mechanisms in documentation
• High · Cookie Handling Security Concerns — websocket-sharp/Net/Cookie.cs, websocket-sharp/Net/CookieCollection.cs. The codebase implements custom Cookie and CookieCollection classes. Improper cookie handling can lead to session hijacking, CSRF attacks, or cookie theft. Without reviewing the implementation, common issues include missing Secure and HttpOnly flags, lack of SameSite attribute support, or improper cookie validation. Fix: Ensure all cookies have: (1) Secure flag set for HTTPS connections, (2) HttpOnly flag to prevent JavaScript access, (3) SameSite attribute to prevent CSRF, (4) Proper validation and sanitization of cookie values
• Medium · Custom HTTP Implementation Attack Surface — websocket-sharp/Net/HttpBase.cs, websocket-sharp/Net/HttpRequest.cs, websocket-sharp/Net/HttpResponse.cs, websocket-sharp/Net/ChunkedRequestStream.cs. The codebase implements custom HTTP parsing (HttpBase.cs, HttpRequest.cs, HttpResponse.cs, ChunkedRequestStream.cs). Custom protocol implementations are prone to parsing vulnerabilities, buffer overflows, and bypasses of security checks. This includes potential HTTP request smuggling, header injection, or malformed message handling. Fix: Conduct thorough security review of HTTP parsing logic. Use well-tested parsing libraries where possible. Implement strict validation of all HTTP headers and payloads. Test against HTTP smuggling payloads and malformed inputs
• Medium · WebSocket Input Validation — websocket-sharp/PayloadData.cs, websocket-sharp/Mask.cs, websocket-sharp/Opcode.cs, websocket-sharp/Fin.cs, websocket-sharp/Rsv.cs. The custom WebSocket implementation (based on RFC 6455) requires careful input validation. The presence of PayloadData.cs, Mask.cs, and Opcode.cs suggests custom frame handling. Insufficient validation could allow attacks such as frame injection, mask manipulation, or denial of service through malformed frames. Fix: Implement strict validation of: (1) Mask requirements per RFC 6455, (2) Frame opcodes and FIN bits, (3) Payload length limits, (4) Reserved bits (RSV), (5) Add rate limiting and frame size restrictions
• Medium · Custom HTTP Listener Implementation — websocket-sharp/Net/HttpListener.cs, websocket-sharp/Net/EndPointListener.cs, websocket-sharp/Net/HttpConnection.cs. The codebase includes a custom HttpListener implementation (HttpListener.cs, EndPointListener.cs, HttpListenerContext.cs) instead of using built-in .NET framework classes. Custom network listeners are prone to security issues including denial of service, resource exhaustion, and improper connection handling. Fix: Review connection handling for: (1) Proper timeout management, (2) Resource limits on concurrent connections, (3) Protection against

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.