Hello
After updating stream_video_flutter to 1.4.1, Stream Video requests fail when the application display name contains non-ASCII characters.
The SDK reads the application name from PackageInfo.appName and includes it directly in the X-Stream-Client HTTP header.
For an application named Giggó Dart's HTTP client rejects this header before the request is sent:
FormatException: Invalid HTTP header field value:
"stream-video-flutter-v1.4.1|app=[DEV] Giggó|app_version=2.5.1|os=android 16|
device_model=Nothing A142"
Steps to reproduce
- Set the Android or iOS application display name to a value containing a non-ASCII character, for example Giggó.
- Initialize StreamVideo.
- Make a coordinator API request, such as creating or joining a call.
- The request fails while setting the X-Stream-Client header.
Expected behavior
The SDK should ensure that X-Stream-Client contains only valid HTTP header characters.
Values collected from the platform, including:
- application name
- device model
- OS name and version
- browser name
should be sanitized or encoded before being added to the header.
Alternatively, instead of collecting application and device metadata automatically, the SDK could expose a public interface allowing integrators to explicitly provide the metadata they want to send:
StreamVideoOptions(
clientMetadata: StreamVideoClientMetadata(
appName: 'Giggo',
appVersion: appInfo.version,
deviceModel: null,
),
);
package_info_plus and device_info_plus would not be needed as SDK dependency then.
Hello
After updating
stream_video_flutterto1.4.1, Stream Video requests fail when the application display name contains non-ASCII characters.The SDK reads the application name from
PackageInfo.appNameand includes it directly in theX-Stream-ClientHTTP header.For an application named
GiggóDart's HTTP client rejects this header before the request is sent:Steps to reproduce
Expected behavior
The SDK should ensure that X-Stream-Client contains only valid HTTP header characters.
Values collected from the platform, including:
should be sanitized or encoded before being added to the header.
Alternatively, instead of collecting application and device metadata automatically, the SDK could expose a public interface allowing integrators to explicitly provide the metadata they want to send:
package_info_plus and device_info_plus would not be needed as SDK dependency then.