fix: handle relative URLs in WebSocket domain filter

[Jah-yee]

Description

Fixes #764 - WebSocket domain filter throws TypeError on relative URLs (e.g. webpack HMR)

Root Cause

The _checkUrl() function used new URL(url) which requires an absolute URL. Relative paths like /__webpack_hmr (webpack hot module reloading) would throw TypeError: Failed to construct URL: Invalid URL.

Fix

• Handle relative URLs by resolving against location.origin
• Return true for URLs without hostname (data URLs, etc.)

Testing

• Code compiles
• WebSocket connections with absolute URLs still filtered correctly
• Relative URLs (webpack HMR) no longer throw errors

[vercel]

Someone is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Suggested change

	// Handle relative URLs (e.g., /__webpack_hmr) by resolving against page origin
	var fullUrl = url;
	if (url.startsWith('/') || url.startsWith('.')) {
	fullUrl = location.origin + url;
	}
	var parsed = new URL(fullUrl);
	return parsed.hostname ? _isDomainAllowed(parsed.hostname) : true;
	var parsed = new URL(url, location.origin);
	return parsed.hostname ? _isDomainAllowed(parsed.hostname) : false;

Two bugs in _checkUrl: manual URL string concatenation produces invalid URLs for relative paths starting with ., and hostless URLs (data:, blob:) bypass the domain filter entirely.

[ctate]

Thanks for the clear bug report and clean PR! One issue: the location.origin + url concatenation introduces a domain filter bypass — //evil.com/socket starts with /, resolves to example.com in the filter, but the browser connects to evil.com. Using new URL(url, location.origin) instead fixes this and also handles ./path correctly. Could you also add a test for relative URL handling? Happy to help work through the details.