Bug: requestModifier triggers JSHttpDataSource breaking video playback for OK.ru CDN

[cheito55]

Description

When a plugin sets requestModifier on a VideoUrlSource or HLSSource, GrayJay sets requiresCustomDatasource = true (in JSSource.kt), which switches to JSHttpDataSource using Java's HttpURLConnection. This breaks OK.ru's CDN (okcdn.ru) which rejects or mishandles requests from HttpURLConnection.

This means:

1. Adding requestModifier with headers breaks local playback entirely
2. Using impersonateTarget (curl-impersonate) also triggers JSHttpDataSource if httpimp is available on the device
3. The only way to make OK.ru work is to NOT use requestModifier at all (like YouTube plugin does)
4. But without requestModifier, Cast doesn't work because Chromecast needs the Referer header

Expected behavior

requestModifier should not force JSHttpDataSource for all requests. Local playback should continue using the default HTTP client, while only Cast proxy requests should use the custom datasource. Or provide an option like requiresCustomDatasource = false on the source.

Steps to reproduce

1. Use any OK.ru plugin with requestModifier on sources
2. Local playback breaks (CDN returns 403 or connection fails)
3. Remove requestModifier → local playback works but Cast fails

Analysis

In JSSource.kt: requiresCustomDatasource = hasRequestModifier || hasRequestExecutor. This is too aggressive — it should only apply the custom datasource for Cast proxy, not for local playback.

Suggestion

• Option A: Only use JSHttpDataSource for Cast proxy, not local playback
• Option B: Add a useCustomDataSourceOnlyForCast flag
• Option C: Allow plugins to set requiresCustomDatasource = false explicitly

Plugin affected

OK.ru plugin (unofficial) and any other plugin where CDN requires headers but HttpURLConnection breaks the connection.

[stefancruz]

Could you try replacing the current requestModifier with the following?

requestModifier: {
    headers: {
        "Referer": "https://ok.ru/",
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0"
    },
    options: {
        applyOtherHeaders: true
    }
}

Both Grayjay’s default datasource and JSHttpDataSource use Android’s HttpURLConnection, so the connection implementation alone is unlikely to explain the difference. One concrete difference is that the normal playback path explicitly sets Grayjay’s browser-like User-Agent, whereas the custom datasource does not set one unless the modifier supplies it.

JSHttpDataSource also constructs headers such as Range before invoking the modifier. If a modifier returns its own headers with applyOtherHeaders: false, those player-generated headers are replaced. Setting applyOtherHeaders: true preserves them.

Please let us know whether this restores both local playback and Cast. If it does not, the response code and the logged JSHttpDataSource request headers would help identify the remaining difference.